Hacker News Reader

Comment by zarzavat | Hacker News Reader

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.

View on HN

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.

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?

Reply on news.ycombinator.com