Ethan Furman wrote:
The question I have at the moment is: should `raise as` be an error if
no exception is currently being handled?
I think so.
"raise as Spam" essentially means "raise Spam with the context set to None".
That's actually only useful if the context otherwise wouldn't be None, that
is, if you're raising an exception when another exception is active. Doing it
"just in case" defeats the usefulness of exception chaining, and should be
discouraged.
It is easier to change our minds later and allow "raise as" outside of an
except block, than to change our minds and forbid it.
Example:
def smurfy(x):
if x != 'magic flute':
raise as WrongInstrument
do_something_with_x
If this is allowed then `smurfy` could be called from inside an `except`
clause or outside it.
What's your use-case? The only one I can think of is this:
def choose_your_own_exception(x):
if x < 0:
raise as ValueError
elif x == 0:
raise as SpamError
elif x < 1:
raise as SmallerThanOneError
else:
raise as RuntimeError
try:
something()
except TypeError:
choose_your_own_exception(x)
I don't think we want to encourage such practices. Besides, if you really need
such an exception selector, change every "raise as" to return, then do:
try:
something()
except TypeError:
raise as choose_your_own_exception(x)
Much more clear.
I don't care for it for two reasons:
- I don't like the way it looks
- I can see it encouraging always using `raise as` instead of `raise`
and losing the value of exception chaining.
Other thoughts?
~Ethan~
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/steve%40pearwood.info
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
