this post was submitted on 14 Nov 2023
44 points (94.0% liked)

Python

6343 readers
4 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
you are viewing a single comment's thread
view the rest of the comments

I disagree. I've had to debug messes where errors are only really caught at the top level, and often there's something that programmer could've done to properly handle it but didn't because it wasn't clear that the function they called could produce an error.

And that's where Go and Rust do a fantastic job imo. Since you're forced to acknowledge errors, you give the programmer the opportunity to handle them and take corrective action. I like the Rust syntax a bit more because it's easy to return errors without messing with logic flow, so you can handle all errors at the calling function easily if that's better for logic flow.

The best solution for Python, imo, is a mix. Here are some things I'd love to see that are related here:

  • optional chaining - x = y?.z ?? DEFAULT instead of x = y.z if y else DEFAULT (esp for nontrivial nesting)
  • monads - return can be an error or value, and you need to determine which before unpacking it; could work with optional chaining as well (would return from the function with the error, otherwise continue with the data), or require destructuring (e.g. with match blocks); similar to try/except, but there's no assumption of success

Some libraries used to do it this way, such as Marshmallow (used a monad pattern).

Sometimes its cleaner and more robust this way, and sometimes it's better to throw errors. There should be simple syntax to pick between them (e.g. like Rust's .unwrap()).