2 ms·
This is very interesting. The difficulty in handling errors in large-scale golang programs is one of the primary practical issues I experience standing in the
by heavenlyhash 12y ago
This is very interesting. The difficulty in handling errors in large-scale golang programs is one of the primary practical issues I experience standing in the way of adopting it in sizable projects. Don't get me wrong -- defer() is very powerful.
Mostly. Where error handling truly gets high-friction is when you start having to deal with the idea that errors in golang are basically untyped; never mind that the entire rest of the language is typed, errors are not held to the same standards.
In small projects, this is something I can live with. In large projects, where any of three majorly different subsystems can fail, and they in turn manage other failable components, and I want to compose my error handling to deal with some of these but pass others up... golang has a very difficult time handling this situation. As a result, I'm very interested in libraries that explore the potentials in this area.
If you haven't seen spacemonkey's error handling library yet:
http://godoc.org/github.com/spacemonkeygo/errors http://godoc.org/github.com/spacemonkeygo/errors
... it's a library that's worth a look, and I think using it in the next major golang project I start is going to dramatically improve the maintainability and stability.
I'd be very, very interested in seeing a combination of a smooth flow like this 'try' demo multiplied by typed errors. The ability to catch some types of errors would be very empowering.