3 ms·
Even if this behavior is similar to how Java exceptions work, I love the way go packages are written. Explicit error handling can be tedious, but I’m never con
by chairmanwow1 5y ago
Even if this behavior is similar to how Java exceptions work, I love the way go packages are written.
Explicit error handling can be tedious, but I’m never confused about what some code will do.
Compared to Java where an exception may bubble up 10 layers to a catchall try catch statement, I actually know where the error is coming from.
Would be nice to have this abstracted away with tooling though. I would imagine go generate could be used to great effect in this arena.
- kubb 5y agoI'm just stating a fact, it's slightly unnecessary to reply with your declaration of love for Go. I prefer returning errors as a part of the function result myself, as you would in any decent language encouraging functional programming principles. If anything, it shows that including a feature in a language (exceptions) will not lead to people misusing it if that misuse is not encouraged.
- julik 5y agoGo errors are actually less useful in this case since they do not capture backtraces by default (if I remember well), and invite gratuitous re-wrapping. Most times I had to troubleshoot something it was useful to know the lowest level where the error happened, not the arbitrary level the application/library author decided to be appropriate and missed.
- throwaway894345 5y agoAgreed, there are tradeoffs, but at least Go’s approach has more potential—there’s nothing stopping Go from capturing stack traces and returning them on the error object. On the other hand, exceptions always have the confusing control flow problem.