Home Original page

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

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