raise EXC from None (issue #6210)
Hello. Some time ago I encountered the problem described in PEP 3134 as "Open Issue: Suppressing Context" ("this PEP makes it impossible to suppress '__context__', since setting exc.__context__ to None in an 'except' or 'finally' clause will only result in it being set again when exc is raised."). An idea that then appeared in my brain was: raise SomeException(some, arguments) from None ...and I see the same idea has been proposed by Patrick Westerhoff here: http://bugs.python.org/issue6210 I am +10, as I feel that's intuitive, elegant and status-quo-consistent. And what do you think? Cheers. *j
Jan Kaliszewski wrote:
I think that stating the syntax is the easy part, actually implementing may not be so simple.
I am +10, as I feel that's intuitive, elegant and status-quo-consistent.
And what do you think?
I think that it's well past time to fix this wart with the new nested exceptions functionality. +1 (Actually I'm also +10 but I don't want to start vote inflation.) The wart I'm referring to is that the common idiom of catching one exception and raising another is now treated as a bug in the except clause even when it isn't:
During handling of the above exception, another exception occurred: Traceback (most recent call last): File "<stdin>", line 1, in <module> File "<stdin>", line 5, in mean ValueError: data must be non-empty In this case, there is absolutely no reason to expose the fact that ZeroDivisionError occurred. That's an implementation detail which is irrelevant to the caller. But exposing it complicates the traceback for no benefit (since it isn't a bug that needs fixing) and possibly some harm (by causing some confusion to the reader). It also reflects badly on your code: it gives the impression of an unhandled bug when it is not. In my opinion, although the error context functionality is a big positive when debugging actual bugs in except clauses, the feature should never have been added without a way to suppress the error context. -- Steven
The class method approach I describe in the linked issue is more likely to be accepted - this problem shouldn't need new syntax to resolve. -- Nick Coghlan (via Gmail on Android, so likely to be more terse than usual) On Oct 22, 2011 4:47 PM, "Steven D'Aprano" <steve@pearwood.info> wrote:
I quite liked Matthew Barnett's suggestion: try: x / y except ZeroDivisionError as e: raise as Exception( 'Invalid value for y' ) The rationale is that it's saying "forget about the original exception (if any), raise _as though_ this is the original exception". But how common is this desire to suppress exception context? Furthermore, Nick's suggestion about raising a no-context exception via a class method is very unsurprising behaviour. Encountering: raise ValueError.no_context("can't process empty iterable") is pretty explicit. Also an additional advantage of using the class method is that it *can* be made part of the syntax later if it's clear that it is common enough. +1 to both these suggestions. On Sun, Oct 23, 2011 at 2:20 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
Jan Kaliszewski wrote:
I think that stating the syntax is the easy part, actually implementing may not be so simple.
I am +10, as I feel that's intuitive, elegant and status-quo-consistent.
And what do you think?
I think that it's well past time to fix this wart with the new nested exceptions functionality. +1 (Actually I'm also +10 but I don't want to start vote inflation.) The wart I'm referring to is that the common idiom of catching one exception and raising another is now treated as a bug in the except clause even when it isn't:
During handling of the above exception, another exception occurred: Traceback (most recent call last): File "<stdin>", line 1, in <module> File "<stdin>", line 5, in mean ValueError: data must be non-empty In this case, there is absolutely no reason to expose the fact that ZeroDivisionError occurred. That's an implementation detail which is irrelevant to the caller. But exposing it complicates the traceback for no benefit (since it isn't a bug that needs fixing) and possibly some harm (by causing some confusion to the reader). It also reflects badly on your code: it gives the impression of an unhandled bug when it is not. In my opinion, although the error context functionality is a big positive when debugging actual bugs in except clauses, the feature should never have been added without a way to suppress the error context. -- Steven
The class method approach I describe in the linked issue is more likely to be accepted - this problem shouldn't need new syntax to resolve. -- Nick Coghlan (via Gmail on Android, so likely to be more terse than usual) On Oct 22, 2011 4:47 PM, "Steven D'Aprano" <steve@pearwood.info> wrote:
I quite liked Matthew Barnett's suggestion: try: x / y except ZeroDivisionError as e: raise as Exception( 'Invalid value for y' ) The rationale is that it's saying "forget about the original exception (if any), raise _as though_ this is the original exception". But how common is this desire to suppress exception context? Furthermore, Nick's suggestion about raising a no-context exception via a class method is very unsurprising behaviour. Encountering: raise ValueError.no_context("can't process empty iterable") is pretty explicit. Also an additional advantage of using the class method is that it *can* be made part of the syntax later if it's clear that it is common enough. +1 to both these suggestions. On Sun, Oct 23, 2011 at 2:20 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
participants (4)
-
Jan Kaliszewski -
Matt Joiner -
Nick Coghlan -
Steven D'Aprano