> I'd also exclude:
    > 
    > +-- StopIteration
    > +-- StopAsyncIterat
    > 
    > which are used for mere communication rather than describing real error cases.

Absolutly not. If you implement very low level logic, you can use those. I have to catch them several times in my life.

    > Also, you should exclude:
    > 
    >    +-- SystemExit
    >    +-- KeyboardInterrupt
    >    +-- GeneratorExit
    > 

Certainly not. You should DEFINITLY unit test for those. I do it all the time:

    def test_ready_keyboard_interrupt(aioloop, app):
        beacon = Mock()
        real_stop = app._finish

        def beacon_stop():
            beacon()
            real_stop()

        app._finish = beacon_stop

        @app.on('running')
        def stahp():
            beacon()
            raise KeyboardInterrupt()

        @app.on('stop')
        def stop():
            beacon()

        app.ready()

        assert beacon.call_count == 3

You must check if you app behavre well when killed.

    >         +-- ImportError

That a type system can't check for, but a good linter can. I never have import errors because I got proper tooling.

    >         +-- MemoryError

That you should test for of course. Last week I worked on a split/merge algo on big files. I had to test that.

    >         +-- SyntaxError
    > 
    >         |    +-- IndentationError
    >         |         +-- TabError

Well, doh :) Type system or unit tests won't catch that. Tooling, tooling, tooling.

    > Finally, I would argue that most instances of this exception are caught by a type system:
    > 
    >         |    +-- KeyError

No, no no !

KeyError should be super mega tested:

  - keys can be any mutable in Python, not string;
  - keys are very often generated on the fly, not constants;
  - dict are mutable, you can add or remove keys.