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

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

#51

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

enriquto wrote: post #48

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…

> both cases are equally likely

Both cases are not equally likely, though. Also, this article is not about the philosophical approach to naming errors versus exceptions. It's about the performance of two technical approaches to handling exceptional/unlikely circumstances.

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

#52

Post by asdfasgasdgasdg » Wed, Jan 20, 2021, 4:32 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…

The point of Go's convention isn't really relevant to the question of its relative cost compared to exceptions, is it? I don't see that they so much missed it as didn't evaluate it.

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

#53

Post by grey-area » Wed, Jan 20, 2021, 4:42 PM UTC

kitkat_new wrote: post #16

grey-area wrote: post #15

Earlier quoted context omitted.

Sure but the advantage of explicit returns is that you can easily see where the error is returned and also add context to it. The disadvantage is a little more repeated code, which isn’t IMO a huge burden. With exceptions it is harder to know where or if it might be handled.

How is it easier to know where or if it might be handled? If you return a error, you still don't know nothing, but that a caller in the chain to the bottom might handle it. There is no difference compared to exceptions, except you know that every caller will have to deal with boiler plate no matter if he is interested.

Errors must be passed manually up a call stack if they are not handled, so in practice this encourages handling them as soon as possible. That makes it easier to find where the error is handled.

Exceptions are automatically passed up, so in practice are often caught by one catcher at the top level which is not very useful and has no idea what to do with the error.

It's a very different mechanism. There is certainly more boilerplate with the Go approach.

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

#54

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

asdfasgasdgasdg wrote: post #51

enriquto wrote: post #48

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…

> both cases are equally likely Both cases are not equally likely, though. Also, this article is not about the philosophical approach to naming errors versus exceptions. It's about the performance of two technical approaches to handling exceptional/unlikely circumstances.

> Both cases are not equally likely, though.

Of course, if you call fopen with uniformly distributed random filenames then it is extremely unlikely than such files will exist. Thus it will fail with probability essentially 1. Yet, I don't want my programming language to force me to make an asymmetric distinction between the two cases.

By "equally likely" I don't mean "having equal probability to occur". This is very difficult to model, and it will depend mostly on the usage patterns of the users of the program. I mean that both cases are worth of the same attention and merit an equivalently serious treatment. No need to disparage one of the two cases as an "error" or an "exception" and require a special language construct.

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

#55

Post by asdfasgasdgasdg » Wed, Jan 20, 2021, 5:22 PM UTC

enriquto wrote: post #54

asdfasgasdgasdg wrote: post #51

Earlier quoted context omitted.

> both cases are equally likely Both cases are not equally likely, though. Also, this article is not about the philosophical approach to naming errors versus exceptions. It's about the performance of two technical approaches to handling exceptional/unlikely circumstances.

> Both cases are not equally likely, though. Of course, if you call fopen with uniformly distributed random filenames then it is extremely unlikely than such files will exist. Thus it will fail with probability essentially 1. Yet, I don't want my programming language to force me to make an asymmetric distinction between the two cases. By "equally likely" I don't mean "having equal probability to occur". This is very…

I assure you, the file-does-not-exist case cares nothing for whether you "disparage" it by calling it an error. As for having a special language construct, the performance benefits discussed in this article are one example of why you might want to have one. If you already have it, using it to represent file not found excursions seems reasonable.

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

#56

Post by marcosdumay » Wed, Jan 20, 2021, 5:31 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…

> But that is sometimes the wrong design.

I'd say that's always the wrong design, with a few exceptions that people can expect to find only a few times on their careers.

The entire point of exceptions was to pop the errors up on the stack until you get into a level where you can treat them. The entire reason they were created was because C-style error handling consists nearly all of code popping the errors up, what made C code very hard to read. The great revolution of error handling monads was that they made popping the errors up not require extra code, thus getting the same advantage as exceptions.

Nowadays I suspecct exception hierarchies was a mistake, and that the only reasonable way to have exceptions is to have them explicit. The monadic handling normally does not copy this hierarchy and is always explicit, what makes pokemon handlers something people must go out of their way to create, instead of being the only reliable way to catch them. But going back to the C-style isn't even only reverting minor gains and keeping the large ones, the large gain is handling the errors on the correct place, that Go throws away, the minor gains are verifying things at compile time and making sure the developer knows what errors he is dealing with, that Go takes a modern take.

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

#57

Post by KineticLensman » Wed, Jan 20, 2021, 5:31 PM UTC

klodolph wrote: post #31

ragnese wrote: post #19

Earlier quoted context omitted.

What if we designed a system where there are two kinds of failures that can be returned? One where the caller is forced to address it by the compiler, and one that is transparent to the caller, but can be caught and addressed by anyone in the call stack (probably the top level)? And one could convert one type of failure to the other. So if you call a library function and it returns the force-you-to-address kind of er…

I think everyone has had this distinction on their mind when designing error handling in the past thirty years or so, it’s just that figuring out an ergonomic way to express it is quite hard. In some languages the distinction is between logic errors and runtime errors. In Java, checked and unchecked exceptions. In Go, err and panic. Rust also has Err() and panic!(). If you look at, say, the evolution of the “if” stat…

> If you look at, say, the evolution of the “if” statement, it was a number of years before this “obvious” control structure was added to programming languages

As described [0] and discussed [1] a few weeks ago. Fascinating.

[0] https://github.com/ericfischer/if-then-else/blob/master/if-t...

[1] https://news.ycombinator.com/item?id=25406211

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

#58

Post by marcus_holmes » Wed, Jan 20, 2021, 6:37 PM UTC

masklinn wrote: post #46

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

Yeah it's a convention. It's not enforced by the compiler. It is caught by several of the static code checking tools (and some linters I believe). You can ignore the convention if you want (you probably shouldn't, but you can).

You could make the case that this is a footgun, sure. I prefer to think of it as giving me the right tools to make the right choice in my specific circumstances.

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

#59

Post by marcus_holmes » Wed, Jan 20, 2021, 6:38 PM UTC

knz42 wrote: post #47

marcus_holmes wrote: post #42

Earlier quoted context omitted.

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

Ah ok, thanks for correcting my mis-apprehension :)

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

#60

Post by marcus_holmes » Wed, Jan 20, 2021, 6:40 PM UTC

masklinn wrote: post #49

marcus_holmes wrote: post #44

Earlier quoted context omitted.

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

The language allows you to ignore the convention.

There is a plethora of tools available to allow you to detect if you did that when you didn't mean to. It's just that the compiler doesn't enforce it.