Hacker News Reader

Go and Rust both strike me as languages made by people who HATE Java/C++ style exception handling but thought the best way to deal with it was to invent a language that constantly punches you in the face.

the fact that the most popular Go IDE actually has logic to automatically fold and hide the constant error handling boilerplate and that people seem to have no problem with that makes me feel like I'm taking crazy pills.

I feel like Rust isn't too bad at it: if you want the almost C++/Java level of wrist strain just use anyhow::Error, remember to put ? after fallible calls and downcast to extract the underlying error.

C++ and Java exceptions have non-local flow and it's hard to determine what function can throw what, so if you do want to add error handling cases you would have to inspect every function to know if it throws or not. Yeah, there's noexcept and checked exceptions but one was a late addition that legacy codebases don't use and the other everyone just does throw new RuntimeException(err) anyway.

After several false starts, Rust mostly got this right with returning

    Result<usefulresult, Error>

from most functions, and using "?" for "If the result of this is Error, do a return of the error". There's also a thing where you can write

    foo().context("useful info about foo")?

and pass some more info with the error.

Plus, most things that work like "open" close when their scope closes, so you don't need all that "defer" stuff.

I would have liked a good error hierarchy like Python 2 had, where there was a clear distinction between program-is-broken errors and errors due to external causes. But Rust didn't get that at the beginning, and now it's too late.

I believe the Context trait is from Anyhow, not part of the base Error trait in Rust.

anyhow::Error really does a good job of smoothing out the finicky bits of Rust error handling, it feels and reads a lot better than Go code to me.

Yes, Context is part of Anyhow. That's a legacy problem. Something like Anyhow should have been the base of almost all errors, but it came too late. If you get error handling wrong at the start of a new language, it's really hard to make changes, because the old format gets baked into everything.

> C++ and Java exceptions have non-local flow and it's hard to determine what function can throw what, so if you do want to add error handling cases you would have to inspect every function to know if it throws or not

In general I agree with you, but Rust is already having this problem by people making liberal use of unwrap.

I haven't seen such a problem with unwrap. Newer people use it but are quickly taught to use Err instead. The only times I use it is unreachable!()

C++ exceptions and Rust Anyhow errors lack stack traces by default, whereas Java exceptions capture them by default, aiding debugging. I'm not sure if Rust spans satisfy the same requirements as stack traces; they seem more built around logging and asynchronous execution, than error handling and synchronous code.

I believe the backtrace API was added to stable rust with the most recent release, and so anyhow backtraces should now be available outside of nightly.

Rust did it well, go just didn't. Maybe because go is the new java.

I agree, except that I want checked exceptions. It’s really not different from the error part of an Either return type — and it could be implemented that way on the ABI level.

(And I’m not sure about the local variables idea, because that could become really slow and could effectively duplicate the stack in size, or even more in the case of “suppressed” exceptions).

Adding or removing checked exceptions breaks library users in very painful ways: if you can’t handle an exception, you should rethrow, but this means a wavefront of code breakage downstream, so the library gets pinned and is never upgraded.

The solution to this is exception wrapping, and designing useful exception types in the first place. This is not an issue.

If it wasn’t, libraries would use checked exceptions, and they aren’t.

Yeah, it's interesting how some people think that its axiomatic that checked exceptions are so awful where they're a feature I really value. <shrug>

Every modern Java library I’m aware of, avoids checked exceptions. Java itself recently introduced UncheckedIOException to wrap IOException in a few places. So while it’s not an official deprecation, it’s a sign that something’s not quite right.

Those are just objective facts. I, personally, don’t like this feature either. May be with very different language design it could be better, but as it is, it’s ergonomics is awful IMO. And I have problems to imagine how to rework it to make it work.

Well, arguably Java’s implementation is not the best regarding checked exceptions. Nonetheless I feel we threw the baby out with the bath water here, as a non-inheritance based checked exception system was not really tried and I feel it would be the best of both words. Since in the end, checked exceptions are just Result types which happens to be natively “understood” by the language - it gets stack trace support, auto-unwraps and bubbles up.

What's missing in Java is the ability for methods to abstract over the set of exceptions thrown by the methods it calls, via generics, for morethan a single exceptikn type. This would in principle be possible, similar to variadic template parameters in C++, and would solve the problem for lambdas and Streams etc. It's a bummer that Java doesn't provide this at present.

Java developers are really divided on the topic of checked exceptions, there is no consensus.

Not trying to start a flamewar, but then why don’t just use Java? It is a more concise (seriously), more expressive language with a bigger ecosystem and similar performance (go is better for smaller apps, while java is better for big server workloads). It pretty much already has virtual threads, not much will change regarding its API, so not even that is a difference.

In my experience, go developers I've worked with agree that we hate exceptions.

>Just let me throw exception, collect entire stacktrace, let me catch exception whenever I want or dump stacktrace if nobody caught it and goroutine died.

Go allows you to do that with panic/recover, although it's not quite idiomatic

With entire standard library that’s not just idiomatic. I would need to write wrappers or just rewrite standard library. It’s plain crazy if you ask me. So yeah, theoretically it’s possible to emulate exceptions, but in reality it’s not.

Auto-capture during throw is actually a pretty neat idea. Somewhere between usual exceptions and a heap dump.