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/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4