[Python-Dev] PEP 342 support for string exceptions in throw() (original) (raw)
Guido van Rossum guido at python.org
Fri Mar 24 23:36:22 CET 2006
- Previous message: [Python-Dev] PEP 342 support for string exceptions in throw()
- Next message: [Python-Dev] PEP 342 support for string exceptions in throw()
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 3/24/06, Phillip J. Eby <pje at telecommunity.com> wrote:
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?
-0.
I think it's overkill to warn for any string exceptions thrown this way. Since the only use case for using throw() is to pass an exception you just caught, I don't see that putting the warning is useful -- it's just more code that in practice is never triggered.
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
- Previous message: [Python-Dev] PEP 342 support for string exceptions in throw()
- Next message: [Python-Dev] PEP 342 support for string exceptions in throw()
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]