3 ms·

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

by vog 10y ago

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.

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

by vog 10y ago

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