Errors vs. exceptions in Go and C++ in 2020 • Hacker News Board

Re: Errors vs. exceptions in Go and C++ in 2020

#41

Post by marcus_holmes » Wed, Jan 20, 2021, 3:47 PM UTC

dan-robertson wrote: post #32

jasode wrote: post #10

Earlier quoted context omitted.

>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 copypasti…

Well there is a language that lets you decide how to handle errors separately from the code that actually handles them (eg separating the code that says “please retry” from the code that retries). That language is Common Lisp. But error handling in it is still a pain. The one advantage it has over most exception systems in my opinion is that the equivalent of try-finally is much more common than try-catch. With excep…

Please stop typing. I don't need another reason to learn LISP! I've been successfully stopping myself from entering that rabbit hole for years in order to prevent yet another "hey I should rewrite all my projects in LISP!". Also looking at you, Rust.

Re: Errors vs. exceptions in Go and C++ in 2020

#42

Post by marcus_holmes » Wed, Jan 20, 2021, 3:52 PM UTC

knz42 wrote: post #6

marcus_holmes wrote: post #3

I 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.

> Previously, in Go 1.10, this fixed cost was non-negligible, climbing upwards of dozens of nanoseconds. Thanks to recent improvements in the Go compiler however, as well as general improvements in CPU micro-architectures, this cost has been greatly reduced in 2020.

I read that as "used to be non-negligable, is now negligable"

4%-10% depending on compiler and architecture is pretty variable, to my way of thinking. YMMV.

also kinda random, in that there's nothing I can do in the code to determine how much overhead it costs, or change that (apart from ignoring Go's convention on error handling completely, which I'm not going to do because it wasn't a convention for performance reasons in the first place).

Re: Errors vs. exceptions in Go and C++ in 2020

#43

Post by ascotan » Wed, Jan 20, 2021, 4:00 PM UTC

jasode wrote: post #10

marcus_holmes wrote: post #3

I 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 copypasti…

The problem with 'pokemon' exception handling (you have a 'gotta catchem all' exception handler) is that when someone inadvertantly puts a exception handler somewhere in the middle of the call stack it creates hard to find bugs. I've actually seen this in practice and it's a pain to debug.

Re: Errors vs. exceptions in Go and C++ in 2020

#44

Post by marcus_holmes » Wed, Jan 20, 2021, 4:06 PM UTC

frou_dh wrote: post #12

marcus_holmes wrote: post #3

I 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…

Go's thing is more "encourage" to handle errors than "force", given that the compiler has nothing to say about unhandled errors in the presence of certain variable reuse patterns, or completely unassigned returns. https://play.golang.org/p/mu5fbUrV322

true, good point. And having the power to ignore the convention is good, too.

Re: Errors vs. exceptions in Go and C++ in 2020

#45

Post by marcus_holmes » Wed, Jan 20, 2021, 4:10 PM UTC

akvadrako wrote: post #11

jcelerier wrote: post #4

Earlier 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

Panic works fine; they are basically just exceptions you can catch at a higher level. I almost exclusively use panic for my exceptions in go.

I stopped, because it conflicts so badly with the Go conventions, and because I found myself handling more errors when I didn't use panic.

I think this is one of those things that new Gophers find hard to adjust to, and older ones realise the wisdom of (there's a few of these in the Go learning journey!).

I'm not impugning your expertise or implying that you're inexperienced. It's just something I've noticed.

Re: Errors vs. exceptions in Go and C++ in 2020

#46

Post by masklinn » Wed, Jan 20, 2021, 4:18 PM UTC

marcus_holmes wrote: post #3

I 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.

Except for not even remotely doing that:

1. if a call can fail but returns no useful value (or the caller cares little about it, and thus ignores everything it returns), Go will not complain that you're ignoring the return value entirely

2. if you have several calls which can fail, nothing forces you to actually handle all the errors, because Go doesn't check for that, it relies on the compiler error that a variable must be used:

    v1, err := Foo(false)
    if err != nil {
        fmt.Println("error")
        return
    }
    fmt.Println("first", v1)
    v2, err := Foo(true)
    fmt.Println("second", v2)

will not trigger any error, because the second calls simply reassigns to the existing `err`, which has already been used once, and thus is fine by the compiler.

Re: Errors vs. exceptions in Go and C++ in 2020

#47

Post by knz42 » Wed, Jan 20, 2021, 4:18 PM UTC

marcus_holmes wrote: post #42

knz42 wrote: post #6

Earlier quoted context omitted.

> 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.

> Previously, in Go 1.10, this fixed cost was non-negligible, climbing upwards of dozens of nanoseconds. Thanks to recent improvements in the Go compiler however, as well as general improvements in CPU micro-architectures, this cost has been greatly reduced in 2020. I read that as "used to be non-negligable, is now negligable" 4%-10% depending on compiler and architecture is pretty variable, to my way of thinking. YM…

You're mis-reading the text.

The reduction in cost pertains to the try/catch (defer/recover) mechanism, not error returns.

The cost of error returns has not reduced since Go 1.10.

Re: Errors vs. exceptions in Go and C++ in 2020

#48

Post by enriquto » Wed, Jan 20, 2021, 4:20 PM UTC

As a famous software philosopher said (I think it was Uriel): errors are wrong.

Or, to put it more clearly: there are no errors, only conditions that you dislike. It's better to not burden your programming with your emotional shortcomings, and treat all conditions that you may encounter on an equal footing.

You try to open a file; the file may or may not exist, and both cases are equally likely and you get to decide what your program does in each case. No need to attach an emotionally charged label like "error" in one of the two cases of the conditional. Or worse, as some emotional fanatics do, to bend an otherwise clean programming language by adding features (e.g., exceptions) that help support your sentimental disposition.

Re: Errors vs. exceptions in Go and C++ in 2020

#49

Post by masklinn » Wed, Jan 20, 2021, 4:20 PM UTC

marcus_holmes wrote: post #44

frou_dh wrote: post #12

Earlier quoted context omitted.

Go's thing is more "encourage" to handle errors than "force", given that the compiler has nothing to say about unhandled errors in the presence of certain variable reuse patterns, or completely unassigned returns. https://play.golang.org/p/mu5fbUrV322

true, good point. And having the power to ignore the convention is good, too.

> And having the power to ignore the convention is good, too.

Mistakenly not handling errors is not "the power to ignore the convention", it's "the language is half assed".

"The power to ignore conventions" is being allowed but having to explicitly ignore the error, aka that the second and third cases trigger errors, and that you'd have to write:

y, _ := fmt.Println("Bar") println(y)

_, _ = fmt.Println("Qux")

(also note how you can not use `:=` in the second case, because that requires that there be at least one new variable on the LHS)

Re: Errors vs. exceptions in Go and C++ in 2020

#50

Post by onionisafruit » Wed, Jan 20, 2021, 4:22 PM UTC

Cthulhu_ wrote: post #27

jasode wrote: post #10

Earlier quoted context omitted.

>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 copypasti…

Well yeah, but that's a situation that C() cannot predict; it's an unexpected error. 99% of Go's errors are expected errors that can and should be handled - you mention a network connection being down, that's an expected outcome when doing anything related to a network. A memory allocation failure is unexpected, and more down to the OS than the application itself; that's where a panic is in order and a last moment "s…

The convention is to reuse err after you’ve handled any previous non-nil values. That does leave room for forgetting a check. I’ve made that mistake many times, but the errcheck linter finds the mistake every time.