Comment by suresk | Hacker News Reader

Comment by suresk | Hacker News Reader

Parent Full thread

I don't think you're weird - I understand that some people like it and I can kind of see some of the arguments as to why - but the error handling in Go is easily my least favorite thing about it. For two reasons:

1) The aforementioned boilerplate code that makes up a significant chunk of many Go projects and adds no value.

2) With explicit error handling, however deep your call stack is, you are relying on everything in that stack to have done the right thing with regards to error handling. With exceptions, you have to go out of your way to screw them up.

I can't tell you how many times I've gotten dumb error messages like "Invalid string" from a 3rd party library that take forever to debug, and accidentally swallowing an error is even worse. A simple (even crappy) exception message + a stack trace is much easier for me to use for debugging than even the best handcrafted error message in 99% of cases.

I write somewhat equivalent amounts of Python, Java, and Go lately, and each one has their good and bad parts, but there are few things I dislike as much as Go's error handling patterns.

> With explicit error handling, however deep your call stack is, you are relying on everything in that stack to have done the right thing with regards to error handling. With exceptions, you have to go out of your way to screw them up.

I don't think I agree with this argument. In many languages, there's no obvious indicator that any given function may or may not raise / throw an exception. And even if it doesn't throw an exception today, it might tomorrow, and it's easy to forget to update all callers.

Since Go makes errors a return value you have to actively discard the result (by replacing it with a underscore, e.g. `res, _ := getResults()`) or take the time to handle the error.

And just like an intermediary library in Go can swallow the error, so can an intermediary library in an exception language catch and discard an exception.

It seems to me that the result is more errors are properly handled in Go - because they are explicit - while uncaught exceptions often cause bugs that make it to production.

For context, I recently switched jobs from one where I wrote Python for 4.5 years to a job where I've been writing Go for about 5 months.

> With Go making errors a return value you have to actively discard the result (by replacing it with a underscore, e.g. `res, _ := getResults()`) or take the time to handle the error.

Right, but because `err` ends up getting re-used in so many cases, you can re-assign it and forget to do anything about it (which is what I've found in most cases where an error was inappropriately suppressed in Go).

In most cases, simply bubbling up the error to something that will generically handle all errors is the right thing to do, and in the case of exceptions, even if you don't know about one, that is what will happen. I just sampled a handful of the top Golang repos on Github, and found very few cases of anything more than the standard `if err != nil; return nil, err' pattern that just bubbles the error up.

> Since Go makes errors a return value you have to actively discard the result (by replacing it with a underscore, e.g. `res, _ := getResults()`) or take the time to handle the error.

This is a bad thing because it’s not narrow. It’s like a language’s “catch” statement not allowing you to catch specific exceptions. Once someone has decided to throw away an error with the underscore assignment, all future errors the underlying might return are swallowed as well.

In other words, it takes even more boilerplate to have narrower error exemptions than to have the generic exemption.

> It seems to me that the result is more errors are properly handled in Go - because they are explicit - while uncaught exceptions often cause bugs that make it to production.

An error in go that is blindly returned all of the way up the stack has no difference with an uncaught exception.

Last time I wrote go you could write `doThingAndMaybeReturnErr()` without the `_ =`. Has this changed?

The alternative is Zig or Rust's thing, where you still have explicit error handling but you don't repeat the same four lines all the time. This is maybe helpful because in Go one has to read those lines carefully to see if anything unexpected is happening.

Linters such as golangci[1] which will warn if you ignore the return value. If you ever write Go again I highly recommend you look at golangci -- the security checks have been really helpful to me.

[1] https://golangci-lint.run/

> Since Go makes errors a return value you have to actively discard the result (by replacing it with a underscore, e.g. `res, _ := getResults()`) or take the time to handle the error.

LoadData(&data)

Does this function return nothing or an error ?

It returns nothing or the compiler/linter/ide will tell you.

Which compiler/linter/IDE is that? The Go compiler and linter certainly don't tell you:

https://play.golang.org/p/k-eTs3dC_wK

Note that Go playground also runs go vet, a static analysis tool.

You're probably right. I use Goland and I just think of it as a natural extension to Go. I shouldn't.

There’s two types or reason for a program to error:

- the code has failed and the developer needs to be informed what to fix

- the environment has failed and the user needs to be informed

Exceptions are for the former, which Go still supports via Panic(). Errors are for the latter. Which is why all the boilerplate Err code creeps in.

I don’t like getting stack traces from applications when I’m a user. It always feels to me like the application is only half finished. When the error is environmental (eg file system permissions) a stack trace just muddies the water with unnecessary output.

This is why I like Go’s distinction between errors and exceptions.

This is great in theory but in reality no such distinction exists. For example, is trying to read a missing file a failure of the code, or a failure of the user? It could easily be either, the developer hardcoded the file path wrong during development, or the user selected a wrong path in a CLI, ... the distinction between errors and exceptions must made by the call site, not the definition site. The code calling readFile() knows whether the error is recoverable or not. readFile() itself does not, so the same mechanism should be used for both errors and exceptions.

All this was figured out decades ago, that's why exception systems were invented, but language designers keep making the same mistake over and over again in an effort to simplify the unsimplifiable.

Except that people are too lazy to use exceptions that are checked at compile time.

The main benefit of Go is that the people that defined the library ecosystem actually decided to handle errors. It's the bare minimum, but it's better than just forgetting that the error exists and not documenting it either.

The language is ... not the best, but the libraries tend to be more robust.

It’s not always laziness, in Java

  stream.map(f)

doesn’t allow f to declare any checked exceptions. We could catch and wrap everything but that obscures the useful code without any improvement in safety.

Libraries can almost never handle errors - they can only signal them. And Go libraries are particularly bad at this, because they almost always return error strings, instead of meaningful error types, which means you can't easily handle a subset of errors. Even if you did, Go's errors suffer from the same problems as exceptions in many languages: there is no way to document what errors your function can actually return, just that it returns some error.

What language are you thinking of when saying Go libraries do better at error handling?

In your example, it should be an error because it’s an environmental problem (could be file system permissions). Sure, it could be a developer fail where they hardcoded the wrong path (surely any kind of testing would pick this up?) but it’s still an error in the environment where had the path been correct it could fail due to something the user misconfigured. So it needs to be handled as a user facing error.

Exceptions do exist in Go, it’s called “Panic”. This whole “Go doesn’t have exceptions” meme is completely untrue. It’s just not the preferred way of error handling because, unsurprisingly, most application errors are going to be environmental. But if you select an out of bounds index in a slice or don’t handle a nil pointer correctly you’d get a panic — because those are clearly developer issues that warrant a stack trace rather than environmental problems that need a friendly user facing error message.

If you make it an environmental error then the programmer is likely to write an error handler that ignores the error because it can "never" happen and the compiler is forcing them handle it. You now need a linter to prevent this and a way to signal to the linter that "no I really intended to ignore that error, I promise"

Whereas exceptions fail safe, ignoring the error means not catching it, which means if the error does occur, it will load up the debugger.

This is the whole Java "checked exceptions" misfeature again.

This makes no sense. Plus naff developers can be just as lazy with exceptions if they wanted. A try/catch block can be abused extremely easily.

>Exceptions are for the former, which Go still supports via Panic().

The panics are there to be used only in cases where the further code execution is impossible. Not to inform the developer about an error.

Errors are a general solution to report an unexpected event during execution. The destination of such report depends on the part of code the program failed.

I get that what you’ve posted is the official description but it doesn’t really explain the distinction well IMO. Eg there are plenty of environmental reasons you’d need to cease execution but giving the user a stack trace isn’t helpful. So be describing the two as who the target recipient of the error is helps. Or at least I think it does.

Personally my one gripe with Gos errors is that EOF is handled as an error.

> Eg there are plenty of environmental reasons you’d need to cease execution but giving the user a stack trace isn’t helpful.

Not sure I got this part. If you want to stop the program and don't to print the usual panic messages into the console - you can log\print whatever you want and call os.Exit().

At the same time you can log stack trace without panicing.

>Or at least I think it does.

Maybe, it's just that "the code has failed and the developer needs to be informed what to fix" applies to errors just a much as to panics. The only difference is that an error is the situation during the execution where you can continue the job and a panic requires execution to stop (in most cases).

At the same time panic are 'developers only'.

You’re arguing the same points I’m making :)

Your entire argument rests on the weird assumption that the User is responsible for the environment. In the vast majority of software used today, that is not the case.

In SaaS, mobile, and appliances, the environment is entirely or almost entirely controlled by the programmer - a missing file is the developer's problem, and the user can't do anything about it.

In enterprise software, there is a third entity, the Administrator, that has (almost) full control over the environment, and usually there are layers of 3rd party software that control it directly. A missing file or permission error is useless to the user, most likely it needs to be logged somewhere that Admins check, and the user simply told to contact their Admin.

Finally, even in personal desktop software, the environment is jointly owned by the user and the developer - the developer is normally responsible for setting up the initial environment through some kind of installer (msi, deb, make configure etc.), and many environment issues are bugs in the installer, not user errors.

Of course, the same library may very well be used in all of these vastly disparate deployment scenarios - the library can't decide what is the source of an error, so making it arbitrarily decide between two possible kinds of errors is wrong.

Note that even the reverse is not clear; an index out of bounds error could be a user problem - if they are trying to access the 7th element of a 5 element list. The fact that you'd normally do

  if userSelectedElement > len(arr) {
    return nil, fmt.Errorf("Array index out of bounds")
  }
  return arr[userSelectedElement], nil

Is only because of the convention you were proposing - `return arr[userSelectedElement]` does the same thing alone, if we disregard the convention (in a memory safe language, of course!).

Your argument is just reinforcing the reason for errors to be concise and to the point rather than displaying a stack track when it’s not the developers who are administering the application.

Trust me, searching through a stack trace on a centralised logging system isn’t fun.

> Finally, even in personal desktop software, the environment is jointly owned by the user and the developer - the developer is normally responsible for setting up the initial environment through some kind of installer (msi, deb, make configure etc.), and many environment issues are bugs in the installer, not user errors.

Desktop Linux, yeah. It’s seldom that simple in servers though. SELinux, custom config, custom iptables rules, network wide UIDs (eg shared storage volumes), there’s so much that can go wrong the moment you do enterprise.

> Note that even the reverse is not clear; an index out of bounds error could be a user problem - if they are trying to access the 7th element of a 5 element list. The fact that you'd normally do

If you’re writing software that doesn’t do input validation and bounds check then you’re a failure of a developer. Sorry but this is the bare minimum I’d expect a developer to do.

> Trust me, searching through a stack trace on a centralised logging system isn’t fun.

A stack trace is still better than a one line error with no context. It's a kind of 80% solution - it's not ideal (a perfect error includes only the relevant context), but getting it's much better for 0 effort than error codes/values give you for free.

> If you’re writing software that doesn’t do input validation and bounds check then you’re a failure of a developer. Sorry but this is the bare minimum I’d expect a developer to do.

So what is the profound difference between doing input validation in your own code vs letting the array accessor do it?

> A stack trace is still better than a one line error with no context. It's a kind of 80% solution - it's not ideal (a perfect error includes only the relevant context), but getting it's much better for 0 effort than error codes/values give you for free.

Yeah, a stack trace is better then an “undefined error” type message. But the point of forcing error messages over exceptions is you’re enabling you’re developers to write meaningful error messages. So your point is moot.

> So what is the profound difference between doing input validation in your own code vs letting the array accessor do it?

- Meaningful error messages (eg has the code failed because of a bug or because of invalid user input?),

- security hardening,

- reducing potential undefined behaviours,

- thorough unit testing,

- self documenting code (the code clearly defines what the happy path is and when it’s possible for a user to break out from that)

Etc

> With exceptions, you have to go out of your way to screw them up.

I remember well java codebases littered with:

    try { .. } catch() { // Todo }

Usually cheaply inserted by the IDE.

I'm pretty sure nowadays there are linters that will ensure you have to do some extra work to actually check in such code, but still...

I've never had a Java IDE insert something like that?

But either way, you have to go out of your way to do that, which is sort of my point.

The one place where you do see dumb boilerplate and chances to screw up is in dealing with checked exceptions, which have been controversial since the very beginning. I think they are one of those things that seem like a great idea in theory, but end up not working out so well in practice, but (like people who appreciate Go's error handling model) there are people who disagree.

Exactly. It is kinda obvious that someone is doing something wrong with the code when they're doing a generic catch (sometimes it is fine, but this will at least raise some eyebrows).

However it is very easy to do the wrong thing using Golang. Just one random library doing `fmt.Errorf` without the `%w` verb is sufficient to lost all information from there on. I would much prefer some kinda of annotation that does the correct thing by default (wrapping the error) instead of the "every error should be explicitly" approach of Golang.

> I've never had a Java IDE insert something like that?

yeah this indeed happens with checked exception and careless developers just wanting to get stuff to compile (we'll handle that property later) and the IDE helpfully providing the boilerplate that resolves the compilation error (and assumes you'll fill the body)

The above code is probably caused by checked exceptions. In particular, the user wants to implement some interface or override some method, but that method wasn't declared to throw a particular type of exception because the people who wrote it hate extensibility and never want their software to be used in a way they didn't anticipate, so the new implementation can't throw it either.

Reply on news.ycombinator.com