[Python-ideas] raise EXC from None (issue #6210)

[Matt Joiner]

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 at gmail.com> wrote:
> 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 at pearwood.info> wrote:
>>
>> Jan Kaliszewski wrote:
>>>
>>> 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 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:
>>
>> >>> def mean(data):
>> ...     try:
>> ...             return sum(data)/len(data)
>> ...     except ZeroDivisionError:
>> ...             raise ValueError('data must be non-empty')
>> ...
>> >>> mean([])
>> Traceback (most recent call last):
>>  File "<stdin>", line 3, in mean
>> ZeroDivisionError: int division or modulo by zero
>>
>> 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
>> _______________________________________________
>> Python-ideas mailing list
>> Python-ideas at python.org
>> http://mail.python.org/mailman/listinfo/python-ideas
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>
>