At 03:06 PM 3/24/2006 -0800, Guido van Rossum wrote:
>On 3/24/06, Phillip J. Eby <[EMAIL PROTECTED]> 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.
_______________________________________________
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
