The cost of Go's panic and recover

I don't know about C#, but in my Java IDE when I set a breakpoint on an exception I can set a filter not only on the class being throw, but also on the class that catch it, the one that throws it and the caller method, and to trigger only after another breakpoint is hit or it is the nth times it has been passed. With this you can make it trigger only when needed in a farly easy way

Well, "break on exceptions" can be very powerful when used correctly, i.e. when the scope is narrowed down. It should never be a flag that is turned on all the time -- that's guaranteed misery there.

> quickly work your way to the first err != nil while debugging

I doubt you'll spend any less time debugging in Go. If you disagree, I'd love to see a "side-by-side" comparison for code that's functionally the same but written in both Go and JS, and see some explanations why it's easier in Go

> Not sure what go debugging is like but I imagine you can quickly work your way to the first err!=nil while debugging.

How do you imagine that happening? I can’t see another way then either stepping through your code or setting breakpoints on all the ‘return nil, err’ statements. You rarely, if ever, can use a ‘watch variable’ feature, because each function will have its own local ‘err’, and will have a new one on each invocation.

If, instead of ‘return buil, err’, there’s ‘throw new…’ in such blocks, I don’t see why you couldn’t do the same things.

That's very opposite from my experience in c++. Enabling break on throw in gdb or lldb always brings me exactly where I need to be no matter the OS / platform. But the software in c++ pretty much always adheres to "exceptions only for exceptional circumstances" and thankfully let them bubble up without rethrow à la java, otherwise it would be absolutely terrible developer ux

You can limit those to code you write. But it sounds like you break also on code that you didn't write eg, libraries or modules. Of course you're miserable.

The go standard library also recovers from panics internally in some places, for example for gradient descent parsers.

Terminology is a problem here. A crashed harddisk is clearly an exceptional circumstance. More specific terms is needed to distinguish errors in the code (eg divide by zero) from unpreventable errors like network failure.

>Exceptional circumstances, or exceptions for short, mean "things aren't working as expected due to programmer error".

Interesting. In Javaland this describes assertions, and the term exception is for operating errors, i.e. problems not necessarily attributable to programmer error, including your example of a network failure.

In Java I always see exceptions being used for stuff like validating HTTP requests

Sounds like Go to me! Every single function that can fail has to return an error value, which is nil if you have succeeded.

I love Go, but its error handling leaves so much to be desired. I even have an Emacs macro that inserts "if err != nil" for me. Also very easy to make a mistake in the rare case where you have to write "if err == nil"; my eyes just skip over any line that includes the words "if", "err", and "nil", as if it was some attention-hungry inline ad.

Rust started off chatty, but soon introduced the "?" syntax, which works perfectly well in the 99% case. Go had a couple of similar proposals, but "keep if err != nil" just... won.

That's why in Haskell after the Either monad becomes popular, people simply made a library that flips the arguments to become the Success monad.

The problem with most languages here is the name "exceptions" implying it's for exceptional scenarios, but without any substitute for good non-local control flow.

"The alternative is every single function has to return a boolean"

Rust: Return Some(value) or None

Another alternative is setjmp/longjmp.

Its strange that its 2025 and we haven't compiled recursion as a design pattern with rules, like a framework, using which all problems that can be solved by recursion can be represented.

You do need to use it, not to handle errors but to avoid it taking down the whole process (and probably sending some logs / alert / monitoring). Which doesn't apply everywhere, but at least in web dev it does: if a request / task panics, you want to abort just that, not the whole server including any other requests / tasks running.

Sadly, you need every goroutine to have its own recovery handler. This works well for your general request / task entrypoints, as there should only be one for each kind, but you need to watch out for any third-party libs spawning goroutines without recovery. They will take down your whole server.

Exactly, same as panic! in Rust.

There is a reason Rust was reluctant to add std::panic::catch_unwind at first. The docs thus explicitly mention that (1) it is not a typical exception mechanism and (2) that it might not even catch panics if unwinding is disabled (common for embedded and restricted development).

panic/recover is the same thing as exceptions. You can avoid them if you want, that's your decision, doesn't change the technical fact.

Maybe I’m mistaken but isn’t that a hand crafted attack vector to taking down your services?

IIRC, the Must.. functions are typically used at program start, and in cases where you would like the program to stop. At least that's the way I've used it.

For example to read and parse expected templates from disk. If they aren't there, there really is no reason to continue, it's just very very confusing.

https://pkg.go.dev/html/template@go1.24.0#Must

the template and regexp packages have Must variants that panic. They're intended to crash the program on init because of programmer error.

Corporate gRPC services are written with "if err != nil" for every operation at every layer between the API handler and the db/dependencies, with table-driven tests mocking each one for those sweet sweet coverage points.

I would love a community norm that errors which fail the request can just be panics. Unfortunately that's not Go as she is written.

Some are of the opinion that that should be handled a layer up, such as a container restart, because the program could be left in a broken state which can only be fixed by resetting the entire state.

Go never had a stance on "unrecoverable panics kill your program". Go always supported recover, but encourages (correctly IMO) error values because they are more performant and easier to understand. The Go standard library even uses panic/recover (aka throw/catch) style programming in specific instances.

> In most software there's no such thing as unrecoverable panic

Webserver wants to start, binding port 443/80 isn't possible because another process holds that port.

Logging service wants to write to disk. The IO operation fails.

RDBMS want's to access the persistent storage, the syscall fails due to insufficient permissions.

How are any of those recoverable?

For me an unrecoverable error is when my program gets into an unexpected state. Given that I didn't anticipate such a thing ever happening, I can no longer reason about what the program will do, so the only sensible course of action is to crash immediately.

I have to add the obligatory “you’ve solved the halting problem” question here.

Well I meant code that panics intentionally, via a call to panic, I've certainly written my share of off-by-ones ;)

Not a lot, nilaway works quite well.

In Rust you have to explicitly state that you're ignoring the error. There is no way to get the value of an Ok result without doing something to handle the error case, even if that just means panicking, you still have to do that explicitly.

In Go you can just ignore it and move on with the zeroed result value. Even the error the compiler gives with unused variables doesn't help since it's likely you've already used the err variable elsewhere in the function.

> For example, Go's language guards against unused variables or imports, they are a compiler error. Assigning an `err` variable but not using it is a compiler error.

Unfortunately, Go's language design also enables unused variables without any error or warning. They are only sometimes a compiler error.

Specifically, multiple return interacts poorly with unused variable detection. See:

    func fallable() (int, error) {
       return 0, nil
    }

    func f1() {
       val, err := fallable()
       if err != nil { panic(err) }
       fmt.Println(val)
       val2, err := fallable()
       fmt.Println(val2)
       // notice how I didn't check 'err' this time? This compiles fine
    }

I've seen so many ignored errors from this poor design choice, so it really does happen in practice.

Whenever I see people appealing to developers to be "disciplined" I think about those factory owners protesting that they wouldn't need guards or safety rails if their workers were just more careful about where they walked.

If developers were more disciplined Go wouldn't need a garbage collector because everyone would just remember to call `free()` when they're done with their memory...

Rust genuinely will stop you, though. You can't take a Result<T> and get an Ok(T) out of it unless there's no error; if it's an Err then you can't continue as if you have a T.

It doesn't force you to do something productive with the error, but you can't act like it was what you wanted instead of an error.

However, you can make a call without assigning the result at all, entirely ignoring it. That isn’t possible in Rust.

Any language that implements linear types has values that can't be ignored and need to be passed to some "destructor" (could just be a deconstruction pattern assignment/similar).

Examples: Austral, some of these https://en.m.wikipedia.org/wiki/Substructural_type_system#Pr... in particular at least ATS, Alms, Granule, LinearML Though most haven't gone beyond research languages yet.