Hacker News Reader

Comment by vog | Hacker News Reader

I'd also exclude:

        +-- StopIteration
        +-- StopAsyncIterat

which are used for mere communication rather than describing real error cases.

Also, you should exclude:

   +-- SystemExit
   +-- KeyboardInterrupt
   +-- GeneratorExit

        +-- ImportError
        +-- MemoryError
        +-- SyntaxError

        |    +-- IndentationError
        |         +-- TabError

because unit tests won't help you to catch these, either (because they are either thrown directly on program start, or depend of specific system circumstances rather than bugs in your code).

Finally, I would argue that most instances of this exception are caught by a type system:

        |    +-- KeyError

Why? Because most of the time the key is not user input, but a hard coded string, and accessing non-existing properties of an object/struct is caught by most type systems on compile time.

View on HN

    > 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.

>> [SyntaxError, IndentationError, TabError]

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

You need neither unit tests or a type system to catch those. And you also don't need any tooling. The Python interpreter will throw these exceptions as soon as your program starts.

(Unless, of course, you rely on stuff like heavy dynamic importing at runtime, but that's really rare. I usually see this only for web servers in debug mode, where they auto-reload the app after a changed source file. But then my above comment applies: The faulty program crashes right away, you can't miss that.)

    > - keys can be any mutable in Python, not string;

You mean immutable.

Well, in many typed languages, a lookup on a map will return an option type. If the key is in the map, it returns Some(value), but if it isn't, it returns None.

By encoding the possibility of a missing key in the return type, you force the programmer to deal with it in the program.

So in fact, having a good type system can help deal with those kinds of errors as well.

Reply on news.ycombinator.com