Twitter user @DanyX23:
TIL: pyright, the python type checking engine that is used by VS Code, has support for exhaustiveness checking for match statements with union types!
If you add the following to your pyproject.toml, you’ll get the attached warning
[tool.pyright] reportMatchNotExhaustive = true
Same goes for the try/catch exception system where runtime errors can pop up bc you don’t have to handle exceptions
I see three possible ways to go about errors:
- Make the programmer actually handle (not just bubble up) all possible errors, which will at some point break abstractions and make writing any piece of code an exhausting task.
- Make it easy for programmers to ignore errors silently. The worst option IMO as it risks undefined behavior and creates bugs that are hard to replicate.
- Make it easy to surface errors to the caller and halt the execution if unhandled. This is what Python exceptions do and I believe to be the best compromise. Bubbling up errors is given by the language and does not depend on the programmer’s willingness to check for errors like in Go (also no err != nil checks all over the codebase).
The criticism I have to Python exceptions is that there should be a way to explicitly see the exceptions a function raises, maybe as part of the function signature like in Java.
To put it another way, I don’t think errors as returned values are immediately better than exceptions. I like the way Rust handles them for instance, but an unsuccessful .unwrap() is not that different from an unhandled exception. I just wish the possible exceptions raised were explicitly stated.
