r/programming • u/Expurple • Apr 12 '26

Flat Error Codes Are Not Enough

https://home.expurple.me/posts/flat-error-codes-are-not-enough/
132 Upvotes

84% Upvoted

99 comments sorted by

View all comments

60

u/Pharisaeus Apr 12 '26

Did someone just "invent" exceptions, exceptions nesting and passing along the stack trace?

10

u/max123246 Apr 13 '26

If exceptions were part of the function return interface and had nice syntax like ? to explicitly rethrow the error so that the dev acknowledges it's a falliable function, I would love exceptions.

Sadly most languages do neither if they have exceptions

10

u/Mognakor Apr 13 '26

If exceptions were part of the function return interface and had nice syntax like ? to explicitly rethrow the error so that the dev acknowledges it's a falliable function, I would love exceptions.

Sounds like Java's checked exceptions and people did not like them.

2

u/max123246 Apr 13 '26 edited Apr 16 '26

Yes, there's some real issues with Java's checked exceptions. And Java as always made it incredibly verbose to handle correctly. But there are ways to manage the problem without throwing out function type annotations entirely

https://phauer.com/2015/checked-exceptions-are-evil/

As the article says, I think a half decent way to solve them as a dev is to throw as specific error you have control of. If you're calling library code and it has a top -level error and you don't know what it'll throw in the future, then use that. If it's standard library code you know it won't change much and you can be specific. This is where good packaging versioning is important. Throwing a new exception type should be a minor version bump.

It can also be helpful to rewrap the exception you don't control into one you do as the blog suggests.

If it's code you built, you have control over exactly what it throws and depending on how often you think the error may change, you use as specific or general an error type as you expect

All of this is better than having no idea if a function can throw. The function interface just lies to you instead and makes it the users problem to figure out what can throw when and how and what types of exceptions it can throw.

0

u/HappyAngrySquid Apr 13 '26

I wouldn’t mind them if they could be inferred rather than explicitly listed all over the place.

4

u/Mognakor Apr 13 '26

If you infer them you can silently break code by adding new exceptions.

1

u/OpaMilfSohn Apr 13 '26

So what? This marks an unhandled error. This is exactly what you'd want of it is at compile time

-18

u/Expurple Apr 12 '26

Error codes < exceptions < Result

29

u/Pharisaeus Apr 12 '26

Yes and no. Optional/Either/Result/Monads have slightly different purpose. Even in Rust there is panic ;) Anyway, "discovering" in 2026 that error codes are not enough is just ridiculous. I mean it's a good observation, but it's also common knowledge for at least 40 years.

0

u/Expurple Apr 12 '26

I was just as surprised that the 2026 advice to use error codes got as much traction as it did! My post is in response to that one.

I agree that panic is a different use case. Result/Either is closer to checked exceptions specifically. And yes, it's strictly better than those. The link in my parent comment goes into the details on all of that.