how to best filter exceptions on their __cause__ (or __context__)?

Given a base exception type:

class MyModuleError(Exception):
    pass

Suppose we have code that explicitly raises it, using exception chaining:

def foo():
    try:
        #some code
    except (ZeroDivisionError, OSError) as e:
        raise MyModuleError from e

Now, in the calling code...

try:
    foo()
except MyModuleError as e:
    # Now what?

how can I idiomatically write the except clause, so that the exception handling depends on the __cause__ (chained exception)?

I thought of these approaches:

a) using type(e) like:

    # filter here
    t=type(e.__cause__)
    if t is ZeroDivisionError:
        doStuff()
    elif t is OSError:
        doOtherStuff()
    else:
        raise

b) using isinstance() like:

    # filter here
    if isinstance(e.__cause__, ZeroDivisionError):
        doStuff()
    elif isinstance(e.__cause__, OSError):
        doOtherStuff()
    else:
        raise

c) re-raising like:

    # filter here
    try:
        raise e.__cause__
    except ZeroDivisionError:
        doStuff()
    except OSError:
        doOtherStuff()
    except:
        raise e    #which should be the "outer" exception

try:
    foo()
except MyModuleError as e:
    # filter here
    if isinstance(e.__cause__, ZeroDivisionError):
        doStuff()
    elif isinstance(e.__cause__, OSError):
        doOtherStuff()
    else:
        raise

in general, using isinstance() is often considered more flexible and recommended over using type() for type checking.

The re-raising is not recommended. In general, it is not idiomatic to raise something deliberately so that it can be immediately caught¹. It's also less performant (exception handling can involve quite a bit of overhead when the exception is actually raised), and creates a reference cycle between the exception object and the current stack frame, which in the reference implementation of Python will leak memory when the auxiliary garbage collector is disabled. (This is why exception names created with as are explicitly deleted after the except block in 3.x.)

On general principle, isinstance is the preferred means of type-checking rather than comparing type results directly, because isinstance automatically takes subtyping into account. The normal functionality of except accounts for subtyping (e.g. except IOError: will catch a FileNotFoundError, which is normally desirable); it stands to reason that, in any normal circumstance, type-checking of the chained exception should do this as well.

There is no explicit built-in functionality for this; therefore, approach b) is recommended here.

_{¹Yes, for loops are internally implemented this way, using StopIteration. That's an implementation detail, and user code isn't intended to look like it's doing such things.}

At least the performance part of my question can be answered quite easily.

Assuming the following example code:

#!/usr/bin/python3

import timeit
import argparse


parser = argparse.ArgumentParser(allow_abbrev=False)
parser.add_argument("-n", "--iterations", type=int, default=1)
args = parser.parse_args()



class MyModuleError(Exception):
    pass

def foo():
    try:
        f = 1/0
    except (ValueError, ZeroDivisionError) as e:
        raise MyModuleError from e

def wrapper1():
    try:
        foo()
    except MyModuleError as e:
        t = type(e.__cause__)
        if t is ZeroDivisionError:
            pass
        elif t is OSError:
            pass
        else:
           raise

def wrapper2():
    try:
        foo()
    except MyModuleError as e:
        if isinstance(e.__cause__, ZeroDivisionError):
            pass
        elif isinstance(e.__cause__, OSError):
            pass
        else:
           raise

def wrapper3():
    try:
        foo()
    except MyModuleError as e:
        try:
            raise e.__cause__
        except ZeroDivisionError:
            pass
        except OSError:
            pass
        except:
           raise e    #which should be the "outer" exception



t = timeit.timeit(wrapper1, number=args.iterations)
print(f"wrapper1: {t}")
t = timeit.timeit(wrapper2, number=args.iterations)
print(f"wrapper2: {t}")
t = timeit.timeit(wrapper3, number=args.iterations)
print(f"wrapper3: {t}")

Gives, as of CPython 3.11.4 the following results:

$ ./chained-exception-handling.py -n 10000000
wrapper1: 4.373930287983967
wrapper2: 4.534742605988868
wrapper3: 7.319078870001249

Actually, I'm a bit disappointed... I thought the method of re-raising the inner exception might be the most "pythonic" one, but that's also the slowest (will, kinda fits Python, doesn't it?! O;-) ).