Congratulation on a good hack, Jim.
I was, however, hoping for something "cleaner" looking! :-)
( as I expect you were too! )
As to Jaap and Jack's comments on reraising being "dangerous" and
"misleading" -
well - the point was that it would be LESS misleading to just let
the unhandled exception continue unimpeeded, that to mislead by
rasing it AGAIN in an inappropriate place. I'm sure that there
is a way to misuse this feature, but I think I've posted enough
examples of Python "misuse" to show that almost nothing is 100%
safe.
I had considered 'raise' with no arguments as a syntax for 'reraise'.
I went with the other alternative because it seemed more general and
useful. ( However, I'm willing to recant if you show me a truly
"dangerous" ( and innocent looking ) application of it. )
Also, it was suggested by looking at the exception handling code in
ceval.c. The exception type, value and frame are pushed onto the
stack anyway. It doesn't look like it would be hard to change, and
it would be compatable. ( the same could be said for the noarg 'raise'. )
I do agree, though, that it's sometimes a pain to dig the values out
of sys - especially when you get sys.last_* mixed up with sys.exc_*
like I did recently, or when you try to access one of those values
BEFORE they actually exist.
I would probably favor Jaap's suggestion of the addition of an
"exception-object" . I need to think more about the sematics and
implementation. A exception-object could have somewhat more structure
that the ( type, value ) exception strings, and could certainly be
easier to parse. ( But would more "heavyweight" exceptions be a pain
in those cases where exceptions were used as a shortcut for testing
cases ( Name or Attribute existance, for example ) first. )
If exceptions were made into Objects, that would suggest to me
that they were also returnable from functions. We would want to
make sure that exceptions had a rather restricted set of operators
and methods ( if any ), so that:
1 + f(x)
would cause an exception if f(x) returned an exception.
[ but: "y=f(x); if sometest(y): ... " should be legal, where
sometest(y) is a test on an exception object. ]
( Returning Exception/Error objects is a completely alternative model
from the try/except model - I'm not sure that they can be made
compatible with each other. )
Another possibility would be for 'except' to take a more complete selector
expression of what exceptions it accepts: If the expression eval's to
true, it is caught. The current syntax would be considered as
shorthand for something like 'exception in flatten( except_list )'
Yeah - a lot of these threads have nine ( or more lives. )
This is not just a feature of the python-list, but due to the
fact that a lot of these questions ( exception handling, inheritance
of interface vs inheritance of implementation, multiple-values, etc. )
are unsolved problems in computer science and computer language
design. ( "unsolved" in the sense that these is no strong consensus
of "the Right way" yet. )
Python has been USEFUL, but one of the reasons it has been FUN (for me)
is that it keeps stumbling into those potholes. :-) Perhaps this is an
aspect of the language still being in a growing and evolving state.
- Steve Majewski (804-982-0831) <sdm7g@Virginia.EDU>
- UVA Department of Molecular Physiology and Biological Physics