Errors vs. exceptions in Go and C++ in 2020
1–10 of 73 posts
Re: Errors vs. exceptions in Go and C++ in 2020
#2Are they going to do this again after Go has switched to a register-based calling convention? https://go.googlesource.com/proposal/+/refs/changes/78/24817...
Re: Errors vs. exceptions in Go and C++ in 2020
#3I think they missed the point of Go's convention. It's designed to force people to handle the damn error as near to the call as possible.
I've seen way too many programs with a single exception handler right at the base of the program, that just goes "whoops, something bad happened, bye!". I've even seen this anti-pattern used with Go's panic-recover mechanism.
It's an interesting find though, that the actual performance cost for checking the error return is random, variable, and small. Good to know :)
Re: Errors vs. exceptions in Go and C++ in 2020
#4I think they missed the point of Go's convention. It's designed to force people to handle the damn error as near to the call as possible. I've seen way too many programs with a single exception handler right at the base of the program, that just goes "whoops, something bad happened, bye!". I've even seen this anti-pattern used with Go's panic-recover mechanism. It's an interesting find though, that the actual perform…
> It's designed to force people to handle the damn error as near to the call as possible.
which is sometimes impossible to do in any meaningful way which just leads people to put panic in there making the end-user experience much worse than having an exception handler at the base of the program / event loop
Re: Errors vs. exceptions in Go and C++ in 2020
#5I think they missed the point of Go's convention. It's designed to force people to handle the damn error as near to the call as possible. I've seen way too many programs with a single exception handler right at the base of the program, that just goes "whoops, something bad happened, bye!". I've even seen this anti-pattern used with Go's panic-recover mechanism. It's an interesting find though, that the actual perform…
> It's designed to force people to handle the damn error as near to the call as possible. which is sometimes impossible to do in any meaningful way which just leads people to put panic in there making the end-user experience much worse than having an exception handler at the base of the program / event loop
In production code people put panics around? I’ve never seen a situation like this. The convention to not use panic is quite strong
Re: Errors vs. exceptions in Go and C++ in 2020
#6I think they missed the point of Go's convention. It's designed to force people to handle the damn error as near to the call as possible. I've seen way too many programs with a single exception handler right at the base of the program, that just goes "whoops, something bad happened, bye!". I've even seen this anti-pattern used with Go's panic-recover mechanism. It's an interesting find though, that the actual perform…
> that the actual performance cost for checking the error return is random, variable, and small. Good to know :)
That is certainly not the article's conclusion. The cost is deterministic, constant and non-negligible.
Re: Errors vs. exceptions in Go and C++ in 2020
#7Earlier quoted context omitted.
> It's designed to force people to handle the damn error as near to the call as possible. which is sometimes impossible to do in any meaningful way which just leads people to put panic in there making the end-user experience much worse than having an exception handler at the base of the program / event loop
In production code people put panics around? I’ve never seen a situation like this. The convention to not use panic is quite strong
And yet it certainly is there.
Re: Errors vs. exceptions in Go and C++ in 2020
#8Are they going to do this again after Go has switched to a register-based calling convention? https://go.googlesource.com/proposal/+/refs/changes/78/24817...
Absolutely yes.
Re: Errors vs. exceptions in Go and C++ in 2020
#9FYI these results were presented at the Go Systems Conf SF last December: https://www.youtube.com/watch?v=inrqE0Grgk0&t=15126s
Re: Errors vs. exceptions in Go and C++ in 2020
#10I think they missed the point of Go's convention. It's designed to force people to handle the damn error as near to the call as possible. I've seen way too many programs with a single exception handler right at the base of the program, that just goes "whoops, something bad happened, bye!". I've even seen this anti-pattern used with Go's panic-recover mechanism. It's an interesting find though, that the actual perform…
>It's designed to force people to handle the damn error as near to the call as possible.
But that is sometimes the wrong design.
If you have functions A() --> call B() --> call C() ... and C() has an error because of a memory allocation failure or a network connection being down, sometimes the best context to handle that error is the outermost function A() and not C().
That's why some programmers don't like copypasting a bunch of "if err != nil {return err}" boilerplate across layers when the intentional semantic design is to deliberately autopropagate errors up the stack. E.g. function A() might have more knowledge of the state of the world via code logic to decide whether to retry a broken network connection or simply log the error and exit.
Sometimes handling the error is orthogonal to how a nested call tree is structured. It depends.