"reraise" & Exception Transformation (was Re: Modules implicitly exposing exceptions from other modules)

Randall Hopper aa8vb at yahoo.com
Wed Feb 16 07:39:00 EST 2000

Tres Seaver:
 |Randall Hopper:
 |>   All error exceptions potentially thrown in a method should be documented
 |>   for that method.  
 |>   Module-specific error exceptions should be transformed as they
 |>   propagate up.
 |Leaving the handling of such errors to the client ... simplifies the
 |mechanism library (nntplib), making it less likely to be buggy.

Yes, but it increases the likelihood the client will be buggy.
Particularly if we change the internal implementation (which the client
now depends on).  As you said, the client ultimately needs to deal with the
underlying error.

In NNTP the difference is:



   try:                bunch_of_socket_stuff
   except SocketError: raise NNTPError


Sadly in Python, with this syntax we loose track of the stack frames
between the original exception and this exception transformation (which
would be useful to have if the client doesn't handle the error and we print
a traceback).  But AFAICT this is a feature (or deficiency) of the

Ideally we'd like to be able to "push" a new interpretation onto an
exception stack.  That is, "re-raise" the exception with a different name.

Similar to how we accumulate stack frames going down, we'd accumulate
exception transformations going up.  This would all be printed in the stack
traceback (if the exception wasn't handled):

    Traceback (innermost last):
      File "t.py", line 8, in ?
      File "t.py", line 6, in outer
        except: reraise NNTPError
      File "t.py", line 5, in outer
      File "t.py", line 2, in inner
        raise SocketError

Maybe a "reraise <exception>" statement in Python 2.0?

Randall Hopper
aa8vb at yahoo.com

More information about the Python-list mailing list