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

[Guido van Rossum]

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/)