On 3/24/06, Phillip J. Eby <[EMAIL PROTECTED]> 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/) _______________________________________________ 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
