[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:
> Okay - so allow them without warning or error, even if somebody does
> 'gen.throw("abc")'?

Correct. There's no current code that does this, and I doubt that few
people will write any, so I don't see the value of trying to trap or
warn for this case.

> 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.

I'm not sure either -- but there's so much convoluted code that I
can't prove to myself it can't happen either.

> 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.

And I see no reason to complicate the code with an additional check
that doesn't serve a purpose. The purpose of reminding people not to
write g.throw("abc") seems artificial to me. I'd rather see less code,
meaning less maintenance, and no need to remove the check later (or
when I merge your changes into the p3yk branch).

--
--Guido van Rossum (home page: http://www.python.org/~guido/)