How do I know all thrown exceptions of a function?

[D-Man]

On Tue, Jan 23, 2001 at 06:48:45PM +0000, Remco Gerlich wrote:
| Sean Reifschneider <jafo at tummy.com> wrote in comp.lang.python:
| > On Sun, Jan 21, 2001 at 01:02:36AM +0100, Syver Enstad wrote:
| > >Couldn't you use the source?
| > 
| > Yeah, I suppose so.  I don't think you should *HAVE* to review the code of
| > the libraries you call, AND *EVERYTHING* that *THEY* call.  It's not an
| > effective use of my time...  I usually just end up leaving it and track
| > down what exceptions get thrown later.  Luckily, Python exceptions are
| > (almost) user-readable.
| 
| I've been thinking about good guidelines to solve this.
| 
| - Obviously, document all your error conditions.

Yes, obviously.  To answer the original poster's question:  it shoud
be documented by the module/function.  RTFM :-).

| - All the exceptions your code explicitly throws should inherit
|   some base exception defined in your module, so that that can
|   be tested for.

I agree with this.  It makes handling all exceptions of a certain
classification easy.

| - Avoid throwing exceptions that have to do with your implementation
|   to the outside world. If your module function gets an argument that
|   is out of range, resulting in an IndexError, don't just pass that on
|   to the caller but catch it and raise a custom exception yourself,
|   that inherits from your module's standard exception. Hide your
|   implementation.

I agree with this as well.  I did this when modifying a library to
actually throw exceptions :-).  It had try{ ... } catch( Exception e ) {
return false ; } in it.  (Java lib someone else copied from a C lib).
It made the errors much more useful.

| - Obviously trying to change exceptions that aren't caused by your code
|   (like KeyboardInterrupt) is of no use.

How about ComputerExplodingError :-).  

| 
| Comments?
| 

Very good ideas; and like much of Python it relies on programmers
doing the Right Thing rather than trying to make a compiler to do the
right thing instead (a la Java).

| -- 
| Remco Gerlich
| -- 

-D