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