3 ms·
> I'd also exclude: > > +-- StopIteration > +-- StopAsyncIterat > > which are used for mere communication rather than describing real erro
by sametmax 10y ago
> 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.
- rbonvall 10y ago> - keys can be any mutable in Python, not string; You mean immutable.
- vog 10y ago>> [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.)
- wtetzner 10y agoWell, 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.