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

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

#71

Post by akvadrako » Thu, Jan 21, 2021, 10:15 PM UTC

marcus_holmes wrote: post #45

akvadrako wrote: post #11

Earlier quoted context omitted.

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.

For me it was the other direction. I started using err returns because I knew it was idiomatic, but after doing that for months and seeing no benefit I decided it was just idiotic to continue.

When I want to handle an error case locally I still use them, but that's extremely rare.

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

#72

Post by klodolph » Fri, Jan 22, 2021, 4:43 PM UTC

ragnese wrote: post #62

klodolph wrote: post #31

Earlier quoted context omitted.

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…

For sure. I didn't mean to imply that this isn't a legitimately hard problem for language designers. Just being a smart ass. I do think that checked and unchecked exceptions are the right way. The issues that people have with Java's checked exceptions are mostly centered around Java's particular implementation of the concept. The biggest failure of which, IMO, is that you can't write an interface that is generic over…

> The only problem with the Rust approach is that you have an extra if-statement on every single call to a fallible function, to unwrap the success/failure. If it used exceptions, the happy paths would (sometimes) be more optimized, if I understand correctly.

This is an implementation detail, and I’m not saying that lightly—I would not be surprised if future versions of Rust eliminated the conditional, because similar optimizations have been made in e.g. Haskell, and Rust has done some interesting work to optimize the run-time representation of enum types in the past to make them work the way you would expect the equivalent C types to work (e.g. Option).

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

#73

Post by ragnese » Tue, Feb 02, 2021, 1:43 PM UTC

friendzis wrote: post #70

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…

IMO the only way for this to actually work is to have the language/compiler force "exceptions" to be part of function signature. I am not aware of any mainstream language which does this. Without compiler support ANY call can end up throwing an exception and thus ANY call can end up not returning (jumping straight to handler higher up in the call stack).

> IMO the only way for this to actually work is to have the language/compiler force "exceptions" to be part of function signature. I am not aware of any mainstream language which does this.

Java. Also Swift.

Rust also counts if you squint and call Result a checked exception and panic an unchecked exception. It's a little different because you technically can ignore a returned Result- it's just a compiler warning, rather than an error. Similar for Haskell and OCaml.