[Python-ideas] Use `isinstance` check during exception handling

[Michael Selik]

After reading https://github.com/sjoerdjob/exhacktion/ I have a better
understanding of what you want to accomplish. However, I'm still not clear
on where the pain is coming from. If you find yourself writing an if in an
except many times as you described:

    try:
        os.chown("README.md", 100, 100)
    except EnvironmentError as e:
        if e.errno == errno.ENOENT:
            pass
        else:
            raise


Would using a context manager solve your problem?

    class IgnoreNotFound:
        def __enter__(self):
            return self
        def __exit__(self, etyp, e, etb):
            if issubclass(etyp, EnvironmentError) and e.message ==
errno.ENOENT:
                return True

    with IgnoreNotFound:
        os.chown("README.md", 100, 100)


On Wed, Nov 4, 2015 at 9:42 PM Michael Selik <mike at selik.org> wrote:

> Hi Sjoerd,
>
> I'm not clear on what problem this suggestion is solving. PEP 3151 was
> solving the problem of existing code failing to be specific with IOError
> and OSError error numbers. Can you provide some less abstract snippets as
> examples, including surrounding context or a link to a project that has the
> problem?
>
> If I saw `except Exception as e` followed by `isinstance(e, SomeError)` I
> would be very confused as to why `except SomeError` was not better. Is this
> simply for backporting FileNotFoundError?
>
> Michael
>
> On Wed, Nov 4, 2015 at 8:39 PM Terry Reedy <tjreedy at udel.edu> wrote:
>
>>
>>
>> On 11/4/2015 5:02 PM, sjoerdjob at sjec.nl wrote:
>> > TL;DR: Change exception checking logic  from
>> >      err.__class__ in exc.__mro__
>>
>> This is backwards. err.__class__ must be a (true) subclass, not a
>> superclass, of exc, where err = exception instance, exc = exception class.
>>
>> There are two checks in the exception process.  First, for 'raise err',
>> is that err is a instance of StopIteration, which is to say,
>> err.__class__ is a subclass of StopIteration.  To avoid the fakery of
>> __instancecheck__ and __subclasscheck__, I presume this is implemented
>> as something like one of
>>    StopIteration in err.__class__.__mro__
>>    StopIteration in type(err).__mro__
>> (There was a recent pydev discussion about when and why these may
>> diverge.)
>>
>> The second, for 'except exc', is that exc is a superclass (other than
>> object) of type(err).  I presume this is implemented as something like
>>    exc in type(err)[:-1]  # exclude object class
>> This assume that err has already passed the first check above.
>>
>> The `try` doc says "An object is compatible with an exception if it is
>> the class or a base class of the exception object".  This text fails to
>> exclude the object class as a compatible object.  CPython code rejects
>> 'except object:' with "TypeError: catching classes that do not inherit
>> from BaseException is not allowed"
>>
>> > to
>> >      isinstance(err, exc)
>> > Because it is more powerful,
>>
>> ?? This predicate is True more often than the current one because it a)
>> does not exclude exc = object
>>
>>  >>> isinstance(Exception(), object)
>> True
>>
>> and b) accesses exc.__instancecheck__ (which is part of your point).
>> This makes it a weaker predicate.
>>
>> I don't have strong opinions at the moment about the proposal itself,
>> but semantic changes in core python syntax need a PEP (once you think
>> there is *some* support).
>>
>> --
>> Terry Jan Reedy
>>
>> _______________________________________________
>> Python-ideas mailing list
>> Python-ideas at python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20151105/fd8488bf/attachment-0001.html>