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

[Randall Hopper]

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:

   Socket.whatever()

vs:

   try:                bunch_of_socket_stuff
   except SocketError: raise NNTPError

SIDE POINT: 

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
language.

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 ?
        outer()
      File "t.py", line 6, in outer
        except: reraise NNTPError
      File "t.py", line 5, in outer
        inner()
      File "t.py", line 2, in inner
        raise SocketError
    NNTPError


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

-- 
Randall Hopper
aa8vb at yahoo.com