RetroSearch Browse

Fri Mar 24 23:24:09 CET 2006 · https://mail.python.org/pipermail/python-dev/2006-March/062798.html

Should geniter.throw() issue a deprecation warning for string exceptions?

My first thought was yes, since that's what raise() does.

On the other hand, one of the key motivating uses for throw() is to allow 
exception propagation on a coroutine stack.  In this use case, the original 
"raise" of the string exception is what should be warned about.  Issuing a 
warning for the line of code calling "throw()" is misleading, since that is 
not the line that is "wrong".

So, here's what I propose to do instead.  Rather than support arbitrary 
string exceptions, which are deprecated anyway, they should only be allowed 
in the case where a non-None traceback argument is provided.  Thus, string 
exceptions could be *propagated* using throw(), but not *initiated*.

Meanwhile, if you throw() a string exception with no traceback argument, 
you would receive the same error you do now.

Any objections?

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2006-March/062798.html below:

[Python-Dev] PEP 342 support for string exceptions in throw()