Hacker News new | past | comments | ask | show | jobs | submit login

I agree - I find Go's error handling encourages subtle bugs.



Go's errors have basically all the problems of exception handling in previous generation languages (and a few novel ones).

This explains it (tl;dr nobody bothers to formally define what errors they return, and the blindly propagate such unspecified errors, and it leads to ambiguity and unintentional program behavior)

https://www.lainchan.org/%CE%BB/src/1612397614615.jpg

https://www.lainchan.org/%CE%BB/src/1612397701473.jpg

https://www.lainchan.org/%CE%BB/src/1612398029019.jpg


Swift considered this and still decided to have untyped error returns. The issues are:

- wrapping every underlying error in your own error type is not helpful

- but defining every underlying error in your own type confuses your implementation (and especially dependencies) with your interface

- and most errors can't be handled in code anyway

There are a few errors (mostly in file operations) that are individually handled as normal parts of life, but otherwise they really are just there to send back up to the user. It's more important to know where an error can happen than what it is.


The only place I would agree with you is when someone accidentally shadows an `err` variable. Although, I'd probably attribute this more to shadowing than the error handling itself.

Other than that, I can't think of any way the error handling subtly introduces bugs.


Go maps are wonderful examples.

If you index into a map, then you get a tuple (val, err), where `err` is non nil if the value exists, and `val` is the value in the map or "the default construction of the value".

Go also silently discards tuple members - e.g. `v = map[4]` is valid, and silently discards the error.

This kind of means that all go maps can accidentally be defaultdicts (in Python terminology), but it's also an excellent way to introduce bugs without meaning to.


The onus is on the programmer to understand what errors might be returned, which isn't always easily gleaned, especially when calling a function that calls other functions that call other functions, each pushing the error up the stack. The error interface does not provide much information on its own.

The mistake of the programmer missing an error that should be handled in a particular situation could be considered a subtle bug, I suppose. This is different to languages that have compiler-enforced error handling, where if you forget to handle a certain case the code won't compile.


None of that is unique to Go, and, indeed, the question of "what errors may be returned" in general is not solved in any language that I know of satisfactorily, especially once you include any form of polymorphism. Compiler-enforced error handling in general only works on the direct possible errors from the function you just called, not the transitive closure of everything that could have happened, again, especially once you include any sort of polymorphism, meaning that you don't even know at the time you're writing the error handler what the possibilities are, and depending on the language, it may not even be possible to statically know. Don't mistake "option" or "sum types" for a solution to this problem; they aren't.

(The only language I know where this is nominally "solved" is Java if you confine yourself to its checked exceptions, but nobody considers that solution "satisfactory", and indeed can be taken as a rough-and-ready proof that there may not even be a "static" solution to this problem that is usable. I'm beginning to think of it as "Errors don't compose, because they contain every possible pathology that would prevent values from composing." At this point, based on the consistent failures trying to create composable error solutions despite substantial effort poured into it across multiple languages, I am going to operate under the assumption there is no such solution until someone produces one.)


Can you give an example?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: