"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:
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
More information about the Python-list
mailing list