Hacker News Reader

Comment by laumars | Hacker News Reader

Panics can be caught and handled by parent callers and thus behave a little bit like exceptions (not as pretty I'll grant you, but still better than the "no way out other than aborting the process" approach it seems at first glance). However you generally you don't want to catch panics except under rare conditions because panics are intended to be used in "the world is ending" kind of scenarios (it doesn't always work out this way but that is the theory).

For general error handling there is an error object that gets returned by functions. It leads to the often moaned about syntax below:

    if err != nil {
        return err
    }

Yeah it's ugly. Yeah other languages have try / etc. But for all of it's sins I've found it still gets the job done.

View on HN

I don't mind that golang avoids exceptions (it would be better if it didn't have them at all) but I don't understand why they looked around the language landscape and landed on C style return codes as the right path forward.

Monadic error handling has all the supposed benefits the return value style errors but allows for easy composition. After years I'm still infuriated with error handling in golang and it was such an easy thing to avoid.

Thanks for the explanation.

Writing that if-construct after every function call doesn't sound like a lot of fun. In fact it sounds like work!

Honestly, I think I'll wait until Go has matured a bit, before I try it for a side-project.

>matured a bit

If it is not mature enough for you now - it will never be. Right now it is already used in many huge IT companies and extremly popular in China. Writing that if-construct after every function is the design, not the lack of it.

It's easy to criticise this from a visual glance but you have to remember that proper error handling in any language is hard work and often produces ugly code where you need to account for multiple edge cases - many of which aren't serious enough to cause an exception but would still break the program's logic. All Go does is group these conditions into a standard interface.

Furthermore, because Go does unify these conditions, I've found it effective for handling a whole array of differing edge cases that I might have otherwise overlooked. In that regard I've anecdotally found it more effective than most of the habits you see in other languages (I can't say all languages because I haven't used every language out there, but I have developed in excess of a dozen different programming languages over the last 30 years).

In short, in Go error handling becomes a first class citizen rather than a byproduct you begrudgingly need to check for.

Also while it might not be to everyone's tastes, adding "if err != nil {" really does add practically nothing to your overall dev time in real terms.

But I'm not here to advocate one method of error handling over another, nor to try and convince anyone to use Go who might not have otherwise. Obviously you can see I get a little frustrated when people judge it purely on face value but that's because I have spent some time with the language and found it to be surprisingly effective at delivering a stable product.

> Also while it might not be to everyone's tastes, adding "if err != nil {" really does add practically nothing to your overall dev time in real terms.

But how do you compose functions then. You can't write:

    f(g(h(...)))

> when people judge it purely on face value

Yes, I can see that is frustrating. But I already know the style of programming that requires if-statements instead of exceptions, as I have been programming in C a lot, and I don't want to go back to that style because I'm lazy and I'm sure I will forget to handle some errors. I want my language to deal with this. Honestly, is that really too much to ask? Even javascript has exceptions.

> because I'm lazy and I'm sure I will forget to handle some errors

I really think you should try Go before being so convinced about your assertions.

It's not easy to forget error handling in Go.

And letting exceptions bubble up all the way will improve things how?

> It's not easy to forget error handling in Go.

It's very easy to do so if the function has no useful return value or you don't care for it e.g. Writer.Write: https://play.golang.org/p/cPh0PJoz-v

> And letting exceptions bubble up all the way will improve things how?

Errors the developer forgets (or does not want) to handle will trigger a default handler.

In practice, what you end up doing is adding the `errcheck` linter to your build process and it finds all instances of you not dealing with an error return and it's "just-as-good" as a compile time check.

A stack of ten functions doesn't need to explicitly catch and re-raise the exception ten times to get it to where it can be handled.

Sure, and then you have no idea what was executed and what failed. Did you run 9 functions or 1? What do you need to roll back? How do you handle the error?

This is the problem with exceptions. They make it too easy to be lazy with your error handling.... Most of the time it's just catch and log, because the code itself has no way of knowing what failed and what succeeded. This is how you get your program in a bad state.... Because maybe you uploaded the file but didn't set the metadata in the API, because the connection broke between those steps.

With go's error handling it forces you to think about "what happens if the code fails here". Its always obvious what code had been executed and what has not.

To get that behavior in exception oriented languages, you'd have to wrap every call in try/catch, which ends up just as verbose as go, if not worse.

> Sure, and then you have no idea what was executed and what failed. Did you run 9 functions or 1? What do you need to roll back? How do you handle the error?

> […]

> With go's error handling it forces you to think about "what happens if the code fails here".

Did it run 9 functions or just 1? What do you need to roll back? How do you handle the error?

The inner code could have just bubbled an error by hand from a deeper call (or the library could even have used panic/recover internally to do so, the stdlib used to do that). You have no more idea than in the exceptions-based code unless you have the source available right there, which you'd then also have in an exceptions-based language.

> To get that behavior in exception oriented languages, you'd have to wrap every call in try/catch, which ends up just as verbose as go, if not worse.

So your argument in support of Go's error handling is that the very worst case of exceptions-based error handling you can imagine is about as bad as the baseline case of Go's?

"What failed?" is recorded in the exception, along with the stack trace of how we got there. try...finally can perform best-effort cleanup, it's just like "defer" with block scope that fits the rest of the language. But it's not that unusual for server hardware to abruptly die, and no error handler can recover from that. "Uploaded file but didn't set metadata" has to be handled in the design phase. Another server needs to notice there may be some unfinished work (often by retrying idempotently).

> I don't want to go back to that style because I'm lazy and I'm sure I will forget to handle some errors.

Because errors are a returned interface you don't forget to handle them. In fact you have to explicitly tell the language not to handle them by using a _ token on the function call.

However it sounds like your argument is more personal preference regarding coding style (eg it seems you tend to favour Sexpression style of syntax over the C-style of syntax) and that's reasonable enough. I do write a lot of code like that too - albeit not in Go.

>But how do you compose functions then. You can't write

Not all functions have to return an error. You can come across something like func(x, y, func() { ... }) Pretty often.

Anyway, I'm not quite sure how is that different from, say, Ruby's begin...rescue.

> Anyway, I'm not quite sure how is that different from, say, Ruby's begin...rescue.

Ruby lets you write foo(bar(baz())), the rescue block will just coalesce errors in any of the three calls.

And because Go has no generics and its errors are not reified (handled through MRV which is a special language construct) you can't build abstractions like flatmap/then/>>= which would let you compose these functions (or function calls), you have to handroll every instance.

As a special case, Go does allow foo(bar()) if foo takes two args. What it doesn't allow is foo(bar(), baz()) with errors.

> As a special case, Go does allow foo(bar()) if foo takes two args

Good to know (though somewhat disgusting), but for error-returning functions I would assume the external ones would take a single argument aka in foo(bar(baz()) I'd expect

    func foo(arg W) (result X, err error)
    func bar(arg V) (result W, err error)
    func baz() (result V, err error)

Ugh, yeah, handling errors sounds like work because it is.

But imagine the consequences of a program that doesn't do this work. If it is doing something important, fingers crossed.

(Keep in mind: unhandled exceptions are like panics. Not good.)

> handling errors sounds like work because it is.

Writing assembly instructions also sounds like work, and it is, but I'm glad my language/compiler does it for me ;)

Your compiler can't handle errors for you. Error propagation is not error handling.

Well, if(err != nil) return err; pretty much sounds like propagation to me ...

Yes, which is not error handling. Exceptions automatically handle error propagation, which is not the hard part of dealing with errors.

> However you generally you don't want to catch panics except under rare conditions because panics are intended to be used in "the world is ending" kind of scenarios

Strange, I've always heard the opposite: if you write a function that can panic, you always want to handle it in your code that calls the function (which should be the only code that could) because panics should generally not be exposed across a public interface, including the boundary between the top-level Go code to the outside world.

panics are like asserts. They're here to make sure the program is being used correctly. There is no handling of them, if it's not used correctly you crash.

Of course you do not want to use panic in sensitive code. The best example is looking at how panic() is used in crypto/tls (which has a lot of sensitive code! You really don't want a client to be able to crash a server): https://gist.github.com/mimoo/93c33d88222c87fb384b4ca3b04fb5...

That's simply not true. There is no recovering from a failed assert. Go's recover() allows recovering from panics.

Further, it is considered good practice to recover from panics within library API boundaries, and return errors across the API instead. "The convention in the Go libraries is that even when a package uses panic internally, its external API still presents explicit error return values."[1]

[1] https://blog.golang.org/defer-panic-and-recover

Yes, if you use panics for control flow in your package, you need to recover from them and hide that fact from your API. That is not the same as saying that you should recover from any panics that happen inside your library. Unexpected panics basically always indicate a programmer error.

Can you give me example in the standard library where they recover from a panic? So far I've only seen recovery through error handling. I think the crypto/tls example is pretty telling on the way they're using panic for sensitive code. No recovery there.

It's common in parsers. JSON parsing can panic (IIRC), as does the go template parsing code. Would they still write it that way today? I don't know.

In net/http, if a handler panics you don't want it to bring down your entire application. For more info, see https://golang.org/pkg/net/http/#Handler

The encoding/json package is interesting because it uses both panic() and recover() internally in a way more reminiscent to how exceptions are used in other languages (that is, for control flow).

For example, https://github.com/golang/go/blob/2596a0c075aeddec571cd658f7... panics, and https://github.com/golang/go/blob/2596a0c075aeddec571cd658f7... recovers it.

Both uses are quite uncommon, though.

interesting! Yeah this is definitely changing my idea of how panic should be used.

Reply on news.ycombinator.com