Hacker News Reader

Comment by haasted | Hacker News Reader

I love Go, but error handling feels like hand-carried, checked exceptions. And now they figured adding a “cause” field is practical. I’m getting deja-vu with Java exceptions 15-20 years ago.

View on HN

I consider checked exceptions in Java quite a nightmare. You have to specify the classes of exception you might throw as part of your function signature and in all methods which might propagate. This is quite a buerocratic monster, which requires quite a bit of refactoring if your exception signature changes. Alternatively, all methods in the chain tend to catch all and then rethrow others.

The described changes could have been added by anyone in earlier Go versions. These are not things which can be only implemented by the language or compiler implementor, these are just APIs, which are standardized.

You could just use throws Exception instead and check the error like Go does. Its a code smell in Java but so is a million exceptions in your method signature. Most libraries and apis will use a base exception type so keep this to a minimum.

Yeah, there are plenty of ways to abuse and misuse those as well. On the positive side, it's possible to make one piece of error handling for e.g. opening a file and writing to it. Just handle IOException. In Go, I have to do manual error handling for each step that may go wrong, ie. the file does not exist, program doesn't have permission to write to etc. In many cases I just want to handle the simple case of "unable to write to file for some reason".

My thoughts on Go error handling has made me conclude that there is probably no really good way to do it. Every approach will come with a load of downsides.

Reply on news.ycombinator.com