Earlier quoted context omitted.
This comes from a misunderstanding of the reason why exceptions where designed they way they were. The whole point of exceptions bubbling up w/o having to write support code to deal with passing exceptions further is to make it so that the purpose of the function is clear to the reader. Go's exceptions have the same unfortunate property as Java's checked exception. And that's what makes Go's code atrocious. Every oth…
> Go's exceptions have the same unfortunate property as Java's checked exception. Wait what? Here's where you lost me. You don't "throw" errors in Golang. Instead it's common practice for functions to return multiple values, one of which can be an error. Errors are just structs that implement the Error interface. The language (and the compiler by extension) doesn't make you explicitly handle errors. On the contrary:…
In Java of course this doesn't have to happen, but it can end up happening if you chose to have many exception types and different exceptions types when crossing layers (e.g. try { doX(); } catch (IOException e) { throw new MiddleLayerException("failed to do X", e);}).
To be fair though, Java still allows you to write that like this:
try{
x = doX();
y = doY(x);
z = doZ(y);
} catch (XException | YException | ZException e) {
throw new MiddleLayerException("...", e);
}
x, err := doX();
if err != nil {
return MiddleLayerErr(err);
}
y, err := doY();
if err != nil {
return MiddleLayerErr(err);
}
z, err := doZ();
if err != nil {
return MiddleLayerErr(err);
}