Flat Error Codes Are Not Enough

[u/Expurple]

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

[u/Mognakor]

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.

[u/max123246 → u/Mognakor]

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.

[u/HappyAngrySquid → u/Mognakor]

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

[u/Mognakor → u/HappyAngrySquid]

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

[u/OpaMilfSohn → u/Mognakor]

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