[PEAK] "State of the Mountain" doc

[Phillip J. Eby]

At 02:38 PM 1/26/04 -0800, Chad Rosenberg wrote:
>"""
>  exceptions
>     I'd actually like to rename this to errors, or else move the 
> exceptions themselves back to individual packages' interface modules. 
> exceptions actually conflicts with the name of a standard library module.
>"""
>
>If you are going to make changes to peak.exceptions, you may want to also 
>consider creating a peak base exception class followed by some more 
>general categories like NamingException.

Thanks for the response.  Actually, NamingException only exists to provide 
some common behavior that's desirable for exceptions involving operations 
on names.  It's not there to allow catching naming exceptions in 
general.  That sort of base class is more useful in Java where you want 
your method signatures to have relatively short "throws" clauses.

I haven't actually seen a good use case for catching "any PEAK error" or 
"any storage error", so I'm going to have to defer adding base classes for 
that until I see (at least) one useful example.


>That way anything in the above category could be caught in a bundle first by:
>
>     except exceptions.StorageException:
>         ...
>
>     except exceptions.PeakException:
>         ...
>
>as opposed to listing all the variants under the "# Storage" section 
>individually.

Keep in mind that you can always do -- in your own code -- something like:

txnExceptions = (
     exceptions.TransactionInProgress,
     exceptions.BrokenTransaction,
     exceptions.OutsideTransaction
)

    try:
        ...
    except txnExceptions:
        ...

If for some reason you want to handle those errors in the same way.  (Which 
is the part I'm having trouble with; for the most part I didn't bother 
making different exception classes if they should be handled in the same way!)