Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

dr-knz.net

Post reply on HN
Print view View original

21–30 of 73 posts

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

#21

Post by grandinj »

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…

> too many programs with a single exception handler right

For a number of useful applications, this is exactly the right, correct, and most useful approach.

I currently maintain several successful (within our commercial niche) 100kLOC+ programs that largely use such an architecture.

It puts the error-handling code in one place, and enables common logging, recovery, filtering and display.

It means that the vast majority of the code can happily just assume that the world is full of unicorns and light.

And given that it is written in Java, the program just largely keeps on running, even in the presence of bugs and weird edge cases, and suchlike, a feature our users really like.

Human are pretty good at going "OK, so that part of the program is having a bad day, I'll report the bug and keep on using the rest of the program".

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

#22

Post by andreygrehov »

knz42 wrote: post #7
dgellow wrote: post #5

Earlier quoted context omitted.

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.

Panics are rare events that very few functions should ever need to think about. If the library truly cannot set itself up, it might be reasonable to panic (which is why panics are usually in the `main` package only). Once all the invariants have been checked, there is no reason to panic anytime after.

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

#23

Post by gpderetta »

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…

actually the best way is not to catch them. Let the application abort and leave a core file you can inspect with full stack trace from the throw point [1] and context.

[1] I routinely remove "catch and rethrow" from our code base exactly for this reason. There are ways to log and add metadata to in flight exceptions that don't require rethrowing.

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

#24

Post by otabdeveloper4 »

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.

This is always the wrong way to handle errors.

If a function returns an 'error' that needs be handled at the call site, then it isn't an error, it's a variant return type.

Errors are things that can't be recovered from but must be handled to release resources.

You want this to happen in some central place, not scattered ad-hoc in every place where you use resources; releasing them by hand is worse than manual memory management.

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

#25

Post by tankenmate »

The one item I'd really contend is where it says it "makes it easier to ... maintain over time".

That might be true for smaller code bases (tracking down exceptions generated from libraries called from libraries, fun!), or code bases where you don't use closed external libraries (that can generate unknowable exceptions), or you use only synchronous code (because asynchronous exceptions wind up jumping to fishkill, welcome to distributed systems (logically, physically or chronologically distributed)).

[EDIT] fixed thinko

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

#26

Post by DoctorNick »

tankenmate wrote: post #25

The one item I'd really contend is where it says it "makes it easier to ... maintain over time". That might be true for smaller code bases (tracking down exceptions generated from libraries called from libraries, fun!), or code bases where you don't use closed external libraries (that can generate unknowable exceptions), or you use only synchronous code (because asynchronous exceptions wind up jumping to fishkill, we…

thank you for emulating the experience of debugging distributed systems

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

#27

Post by Cthulhu_ »

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…

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 "something serious has happened".

In theory, Java's exception handling is supposed to do the same; checked exceptions for expected errors, unchecked for left-field things.

Anyway that aside, Go's error handling could be better because unlike e.g. the Either pattern, you're not actually required to handle errors and using _ you can easily ignore them. Second, the code style and conventions seem to tell you to just re-use an `err` variable if there's multiple errors that can occur in a function (common in e.g. file handling), which opens up the way for accidentally not checking and handling an error.

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

#28

Post by Cthulhu_ »

corty wrote: post #20
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…

My irony detector is buzzing. You just described err vs. panic in go.

Checked vs unchecked exceptions in Java.

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

#29

Post by knz42 »

tankenmate wrote: post #25

The one item I'd really contend is where it says it "makes it easier to ... maintain over time". That might be true for smaller code bases (tracking down exceptions generated from libraries called from libraries, fun!), or code bases where you don't use closed external libraries (that can generate unknowable exceptions), or you use only synchronous code (because asynchronous exceptions wind up jumping to fishkill, we…

This was clarified in the conf talk [1] [2]: error returns should be used at API boundaries, and panic-driven handling only "within" a component.

[1] https://www.youtube.com/watch?v=inrqE0Grgk0&t=15126s

[2] https://docs.google.com/presentation/d/1WVu4O-ax7punUC2V_XgT...

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

#30

Post by trinovantes »

tankenmate wrote: post #25

The one item I'd really contend is where it says it "makes it easier to ... maintain over time". That might be true for smaller code bases (tracking down exceptions generated from libraries called from libraries, fun!), or code bases where you don't use closed external libraries (that can generate unknowable exceptions), or you use only synchronous code (because asynchronous exceptions wind up jumping to fishkill, we…

This is one of the reasons why I really like monorepos. Tracking down an opaque error from 2 network hops away is a nightmare compared to reading an exception in a call stack
Post reply on HN