Using isinstance() during exception handling for subsequent action

Question

I've read various posts that polymorphism should be used instead of isinstance, and I agree that makes sense when the use of isinstance is checking the subtypes of a class to determine what to do. However, is the use of isinstance acceptable when checking the type of an object in order to do something unrelated to the object itself?

For exammple:

last_little_err = last_big_err = None

for thing in things:
    try:
        thing.dothing()
    except (LittleError, BigError) as err:
        logger.error(err, extra={'thingObj': thing.name})
        if isinstance(err, LittleError):
            last_little_err = err
        else:
            last_big_err = err
    else:
        thing.success = True

if last_big_err is not None:
    raise SuperBigError('A big thing error occurred') from last_big_err
elif last_little_err is not None:
    display_error_warning(last_little_err)

I believe using isinstance here is fine since I am not defining what the objects should do based on their type but rather checking their type to determine which variable should store it for later use. Is my reasoning valid?

Answer 1

This seems like a case when ruthlessly eliminating code duplication causes other problems. If you cannot treat LittleError and BigError the same, do not handle them the same way. The if statement in the except block is a big red flag that these exception types should be handled differently. They do have similar elements, that is both should set the success flag to True. But this would be better just catching both exception types on their own with a duplicate call to set the success flag:

try:
    thing.dothing()
except LittleError as err1:
    logger.error(err1, extra={'thingObj': thing.name})
    last_little_err = err1
except BigError as err2
    logger.error(err2, extra={'thingObj': thing.name})
    last_big_err = err2
else:
    thing.success = True

The code repetition is minimal. The code is easy to read. No need to infer the exception type. I find eliminating code duplication inside exception handlers to be more difficult for precisely the reason you posted this question. I've learned a little code duplication in exception handlers goes a long way towards making exception handling a little clearer. The more obvious you make your failure handling code, the better off your application will be.