Hacker News Reader

Just make it so:

varFoo, err := GetFoo()

if err != nil {

    return err

}

Can be written as:

varFoo := GetFoo()?

Just like Rust, everyone would stop complaining about Go error handling. But they have this absolutist position on syntactic sugar, even for something like this that would make the language that much nicer to look at and work with.

While that may look good for a hypothetical example, I'm not sure how beneficial it is in real-world use. If your higher level functions are directly passing errors from your lower level functions then you start to bake implementation details into your abstractions which becomes a nightmare later when your implementation changes and callers are depending on those details. In reality, you need to deal with the error immediately and, if there is no better option, return your own error that describes the problem in a non-implementation-specific way.

It is possible that with other error-related features added to the language you could avoid those traps, but Go doesn't feature those either, so simply adding that construct without thinking about the problem much more deeply doesn't buy you much.

If you are solving a stop the world when you encounter an error-type problem that might be okay, although I'd argue that you may as well panic instead. But, again, Go isn't designed for those problems and I'm not sure it needs to be. There are already plenty of good languages designed for that type of work.

All of these things are better handled by good old exceptions (with optional checking, even). All in all, handling errors is often not possible locally -- there is no reasonable thing to do with a db connection error for example at its immediate caller.

The reasonable thing is perhaps to log it there at most, and bubble it up (possibly wrapped as you mentioned). It can be handled for example by a request handler, by returning a 50_ error.

Casting errors to exceptions (panic/recover) are considered a valid approach in Go within your application logic. Its built-in HTTP handlers will even 500 out of the box if a panic isn't recovered beforehand.

But other layers of abstraction lose their utility value if they start to make assumptions about the caller. Maybe in your web service a 50x stop the world error is all you'll ever need if there is a database error, but the next guy using the code for another purpose could have very different requirements and when you have to actually deal with errors, exceptions become a royal pain very quickly. As such, the official line is simply that you shouldn't let errors casted to exceptions cross package boundaries.

But, again, Go isn't really designed for stop the world programming and it's okay to use another tool if your problem space is suited to stopping the world.

I don’t get what you mean by stopping the world. An exception (in most languages) only interrupts the executing thread.

By the way, Vlang (https://github.com/vlang/v/blob/master/doc/docs.md), uses "?" as well with error handling. To include it had/has a number of Go wishlist features.

The nature and culture of Go makes it harder to change direction and be as amenable, but the merits of such conservatism is a "depends" type of thing and can mean incorporating things many years after it has become fashionable or accepted.

So if GetFoo returned a non-nil error, would the function abort and immediately return the error?

I'm used to a question mark being around null handling, but you know, JVM languages lol, null is thought about a lot.

Yeah exactly, it makes everything so much more ergonomic, especially with combinators, as in chaining method calls that might return an error

This has been used for ages, goddammit. The question mark idea kinda stops half way. In most of languages, the question mark is always there, implicitly. You have to add ugly code to say "this failure doesn't require bubbling up".

Go is an experiment in the exactly opposite direction: language puts pressure to really handle the error in a meaningful way every time. And if you bubble up, at least describe the situation a little bit better. Or explicitly give up and receive a penalty for that: the `return err` is nothing to be proud of, it's just a visual penalty for _lack_ of error handling.

I'm not saying it's better in every project, I'm saying it's valuable on some projects.

>There are a lot of programs where you don't need to think about errors

What kind of utopian programming job do you have that you don't have to think about errors? An error is not limited to technical issues like packet loss or unable to open socket. Its also "client A attempted to purchase item B which is limited to client C". How do you express this in Go?

I have no idea why people are so opposed to ADTs. Its like sliced bread with butter, or whatever the phrase is. Its not _that_ complicated...is it?

> What kind of utopian programming job do you have that you don't have to think about errors?

My job primarily requires thinking about errors. It is why I wish for Go-style errors in the languages I use.

But on rare occasions I write things like batch scripts, automations, etc. in which failure means addressing the issue in realtime and trying again. There you don't care much about errors other than ensuring that the world stops when an error occurs to allow you to fix the problem before continuing.

While contrived, if you run into a "client A attempted to purchase item B which is limited to client C" error in this space you're probably going to have to phone them up and tell them that you can't process the transaction, apologize for the mistake, remove record of their purchase, and then once complete run the script again. The program crashing with an error message is sufficient here.

Different tools for different jobs.

I like the reasoning behind Go's approach, but the `if err != nil` ends up polluting codebases like Java's checked exceptions did.

I'm not sure what the better way to do it is tbh.

Java's checked exception's could be handled at a single place by a catch, or just marked as `throws`. It was never as verbose as go is.

Maybe, but then, when Jackson is throwing an IOException because of bad JSON, and the file you opened that had the JSON could also throw an IOException, then it's not just catch it at a single place, as you'd generally handle both differently.

> but the `if err != nil` ends up polluting codebases

Pollute implies that it is unwanted, but this is something you do want. It is the most interesting and important part of your application logic. You want it up front and centre for all to see.

I think we all understand the human desire to want to believe that bad things won't happen, but when one becomes an engineer they have to set those emotions aside and realize that bad things will happen and that your job is to make sure that when bad things do happen that the failsafes achieve an acceptable outcome.

> I'm not sure what the better way to do it is tbh.

I'm not sure any better is fundamentally possible within an engineering context. The vast majority of the job is in understanding the failure modes and being able to communicate to the computer how to gracefully deal with the problems when they occur. As such, it stands to reason that the vast majority of the code is going to be related to errors.

If you are programming for hobby/learning purposes, where when bad things happen your program can simply crash with no consequence, there are different approaches that work well, but Go is decidedly not designed for this space. And, frankly, doesn't need to be as there are already plenty of languages designed for that. Go is, quite explicitly, meant to be an engineering language.

I can't agree with that at all. Checked exceptions can all be bubbled up to a single catch if that's how you want to handle it. That hardly pollutes a codebase.

Sure. But the bubbling of checked exceptions adds a lot of "foo() throws DeepUnderlyingException", all the way up to your single catch.

And the worst part is when reading the code in such a situation, it can get very tricky to figure out exactly where the exception is thrown.

There's a reason that the JVM ecosystem has largely moved away from checked exceptions.