Hi,
In the Django thread, I suggested that an implicit "raise from" should
be the behavior whenever an exception is raised directly in
exception-handling code (that is, within an except: or finally:
clause). Ram claimed there were problems with that, but gave no
details; I would be happy to know what these problems are.
The main problem I see with "raise from None" is that it removes the
inner part of the traceback. It expresses the idea that everything that
happened in lower levels is not really interesting -- you should have
all the information for handling or debugging the problem by
considering the flow from here up. I think in most cases where you'd
want to change the type and/or value of an excpetion, this is
unrealistic.
With respect to Ram's current suggestion, I think that for it to really
make a difference, the "raise as" should not be thought of as a
shorthand/variant of "raise ... from", but rather as a variant of bare
raise; that is, it should not create a chained exception, but an effect
of re-raising while changing the exception value (and potentially
type). This, I think, would address Ethan's claim that "this should
really be raise from None", without the cons described earlier; it is a
better expression of the idea "I just want to change the exception being
raised".
To summarize, I am suggesting that
except ExceptionType:
raise as OtherException(...)
Have, more-or-less, the semantics of Python 2's:
except ExceptionType:
traceback = sys.exc_info()[2]
raise OtherException, OtherException(...), traceback
Thanks for your consideration,
Shai.
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/KIELJDFFDWTM3IBX7KYOSZVRATGXDLLS/
Code of Conduct: http://python.org/psf/codeofconduct/
