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

Phillip J. Eby pje at telecommunity.com
Sat Mar 25 00:16:23 CET 2006

At 03:06 PM 3/24/2006 -0800, Guido van Rossum wrote:

On 3/24/06, Phillip J. Eby <pje at telecommunity.com> wrote: > At 03:04 PM 3/24/2006 -0800, Guido van Rossum wrote: > >The current state is that it always allows them, right? > > No. It doesn't allow them. Support for string exceptions was never > actually implemented; I'm trying to implement it now.

Oops, I see. I'm +1 for allowing them, -1 for doing any kind of detection of situations that might not allow them in the future.

Okay - so allow them without warning or error, even if somebody does 'gen.throw("abc")'?

I was proposing to only add support for this if a non-None traceback is supplied. I guess I'm confused as to how you could end up with sys.exc_info()[2] not containing a traceback object.

The idea here was that the only valid use case I can think of for throw()-ing a string exception is when using throw() to propagate a previously-raised exception.

Since throw() is a new feature, it seems reasonable to me to not provide string exception support -- except for backward compatibility needs, such as propagating a string exception that was already raised elsewhere.

Thus, it's not a case of removing support for string exceptions, but rather introducing a new feature that doesn't support creating new code that raises string exceptions.

But, string exceptions definitely should be supported for propagation, because you a coroutine could call some old code that uses string exceptions, so you need to be able to re-throw() them to outer coroutines.

(You're not warning about classic classes either are you?)

Nope.

More information about the Python-Dev mailing list