this post was submitted on 23 Apr 2024
82 points (100.0% liked)

Python

6394 readers
9 users here now

Welcome to the Python community on the programming.dev Lemmy instance!

๐Ÿ“… Events

PastNovember 2023

October 2023

July 2023

August 2023

September 2023

๐Ÿ Python project:
๐Ÿ’“ Python Community:
โœจ Python Ecosystem:
๐ŸŒŒ Fediverse
Communities
Projects
Feeds

founded 1 year ago
MODERATORS
 

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

you are viewing a single comment's thread
view the rest of the comments
[โ€“] [email protected] 4 points 7 months ago* (last edited 7 months ago)

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:

  1. 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.
  2. 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.
  3. 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.