Away from Exceptions: Errors as Values
humanlytyped.hashnode.dev
Away from Exceptions: Errors as Values
1–10 of 145 posts
Re: Away from Exceptions: Errors as Values
#2It looks like GO developers never heard about "not repeat yourself", because after almost each call in GO, you write boilerplate error checking code... So you end up writing at least 2 times more lines of code.
Re: Away from Exceptions: Errors as Values
#3To me exceptions are convenient but in the same way global variables are. Both mechanisms relieve you from (explicitly) passing stuff between callers. The stuff still gets passed only in a way that is less visible and harder to reason about.
Re: Away from Exceptions: Errors as Values
#4It looks like GO developers never heard about "not repeat yourself", because after almost each call in GO, you write boilerplate error checking code... So you end up writing at least 2 times more lines of code.
The article is not about Go, although that was my guess before reading it as well.
Re: Away from Exceptions: Errors as Values
#5Interesting that the author used joi as the example, when the io-ts validation library fully embraces the functional world with success/fail return value from validation. Realistically, the advantage throw has is that if you have a single error handler in a function it avoids the "go" problem of tons of lines of error handling. The other side is that error handling becomes "optional".
Re: Away from Exceptions: Errors as Values
#6It's good to see so much focus on errors. They are essential when trying to build resilient systems. But our approaches are still very immature.
First, to make it clear, this article appropriately points out that exceptions are still necessary and relevant. I disagree with some of the use-cases given, but it's important to recognize that exceptions should still exist in programming languages. Joe Duffy's article about Midori's error model [0] is in my opinion the best reference to actually understand the difference between exceptions and errors and why it's so important to get right. It's a very good article, and it has been posted here before; if you are interested in error handling it's a must read.
Now, about errors as values. Treating errors as values is practical, and in modern programming languages, relatively ergonomic. That said, we already have some other comments in the thread pointing out how sticking to just "errors as values" is often not enough (btw, the article uses Rust, not Go, but anyway...). And it's also important to clarify this: errors are such an integral part of our programs, and have so much to do with flow control, that I don't believe thinking about errors just as values is enough. Sure, they might be "just values" under the hood, but in all programming languages we see either optional results or syntax sugar to be able to handle errors more gracefully. And in most cases, we still feel it's not enough (or it's enough to be practical, but not to be pleasant in many cases). So we should keep the door open, and not pretend we have already solved errors.
Finally, the topic of errors is extremely deep and complex, and when you start introducing other factors like how to report the errors publicly to a non-technical user, maybe in different languages, or whether to log it or send it who knows where, whether to trace or not, how, how to deal with duplicates or similar errors... then you start realizing that we are far from a satisfying and complete model for error handling. We haven't reached this part of the discussion yet.
For the moment, passing most errors as values is the relatively painless way that still allows us to customize errors to our needs. But there's still a long way to go.
Re: Away from Exceptions: Errors as Values
#7It looks like GO developers never heard about "not repeat yourself", because after almost each call in GO, you write boilerplate error checking code... So you end up writing at least 2 times more lines of code.
You can always... not treat errors or exceptions. You also create employment for oncall engineers and debugging tools, I'd call it a win-win-win :) /s
Re: Away from Exceptions: Errors as Values
#8"Which program is easier to read?"
For me it was the second. Am I the only one ?
Re: Away from Exceptions: Errors as Values
#9Personally, i really like having multiple return values, since being able to give a function multiple inputs but only being able to return a single thing always felt weird - if your require any metadata in a language like Java, then you'd have to come up with wrapper objects and so on.
That said, i really dislike the following from the article:
if (error) {
// you can handle the error as you see fit
// you can add more information, end the request, etc.
}
Handling those wouldn't necessarily have to be difficult, in the simplest case just wrap it in an implementation specific exception, like InputBufferReadException regardless of whether you're working with a file or network logic and let them bubble upwards to the point where you actually handle them properly in some capacity, be it with retry logic or showing a message to user, or letting external calling code handle it.
Why? Because whenever you're given the opportunity to ignore an exception or you're not told about it, someone somewhere will forget or get lazy and as a consequence assumptions will lead to unstable code. If NullPointerExceptions in Java were always forced to be dealt with, we'd either have nullable types be a part of the language that's separate from the non-nullable ones (like C# or TypeScript i think), or we'd see far more usages of Optional instead of stack traces in our logs in prod, because we wouldn't be allowed to compile code like that into an executable otherwise.
Of course, that's my subjective take because of my experience and things like the "Null References: The Billion Dollar Mistake": https://www.infoq.com/presentations/Null-References-The-Bill...
I think languages like Zig already work a bit like that: https://ziglang.org/learn/overview/#a-fresh-take-on-error-ha...
Re: Away from Exceptions: Errors as Values
#10To whomever is going to implement this: Please save the stack trace into the error object at its creation time, at least in debug builds.