Re: [Python-Dev] PEP 342 support for string exceptions in throw()
At 02:36 PM 3/24/2006 -0800, Guido van Rossum wrote:
I think it's overkill to warn for any string exceptions thrown this way. Since the only use case for using throw() is to pass an exception you just caught, I don't see that putting the warning is useful -- it's just more code that in practice is never triggered.
My proposal was that throw() should only succeed or fail, never warn. If you throw() a string exception with a traceback, it Just Works. If you throw() a string exception without a traceback, you get an immediate TypeError, just like in the 2.5 trunk now. Is that acceptable? i.e., was that what you were "-0"-ing? The only change is that throw() would now *accept* string exceptions without warning or error, if and only if you supply a traceback. That is, if you are effectively re-raising an existing exception.
On 3/24/06, Phillip J. Eby
At 02:36 PM 3/24/2006 -0800, Guido van Rossum wrote:
I think it's overkill to warn for any string exceptions thrown this way. Since the only use case for using throw() is to pass an exception you just caught, I don't see that putting the warning is useful -- it's just more code that in practice is never triggered.
My proposal was that throw() should only succeed or fail, never warn.
If you throw() a string exception with a traceback, it Just Works.
If you throw() a string exception without a traceback, you get an immediate TypeError, just like in the 2.5 trunk now.
Is that acceptable? i.e., was that what you were "-0"-ing?
Actually that's slightly worse; I'm not sure we guarantee that exceptions you catch *always* have a traceback object associated with them. So -1.
The only change is that throw() would now *accept* string exceptions without warning or error, if and only if you supply a traceback. That is, if you are effectively re-raising an existing exception.
The current state is that it always allows them, right? I don't see a reason to change that, and I don't think you've made a strong argument for changing it -- I don't think the use case matters. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
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.
On 3/24/06, Phillip J. Eby
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. (You're not warning about classic classes either are you?) -- --Guido van Rossum (home page: http://www.python.org/~guido/)
participants (2)
-
Guido van Rossum
-
Phillip J. Eby