this post was submitted on 14 Nov 2023
42 points (93.8% liked)

Python

6347 readers
2 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
[โ€“] SittingWave@programming.dev 0 points 1 year ago* (last edited 1 year ago) (2 children)

I don't really see the point of this approach. The whole bane of programming in low level languages like C is that you had to write one line of code, then 10 lines of error management for that line. Repeat until 500 lines, potentially with gotos in order to rollback previously successful operations. The result was that C was mostly error handling of function calls, and the ways to return such errors were hackish. Add reentrancy and multithreading requirements and it became a mess.

The idea of exception throwing is to forget all of this and have a separate channel where exceptions conditions flow, so the code is mean and lean and just does things, and when something goes wrong it throws a fit. If someone understands and manages that fit, great, there will be a specific handler for that, otherwise it won't.

So I don't really see a big case for going back to the old days of errors as values, because it really, really sucked.

[โ€“] tnuctip@mastodonapp.uk 1 points 11 months ago

@SittingWave @mac

That article isn't really advocating handling _all_ errors as values AFAICS - it just doesn't distinguish between _exceptional_ and _normal but unsuccessful_ paths.

For a wrapper around an HTTP transport, returning HTTP responses instead of raising an exception for stuff like "403 Forbidden" is probably reasonable. Their own example code is full of exceptions, though.

load more comments (1 replies)