3 ms·

My opinion on this is not popular but I absolutely love the way go handles errors. I love that errors are returned by functions and then immediately handled. I

My opinion on this is not popular but I absolutely love the way go handles errors. I love that errors are returned by functions and then immediately handled. I prefer it to the try/catch paradigm where the error is maybe handled somewhere up the call stack

alquemist 6y ago
Granted, explicit error handling is a good idea. At some level, it depends on the personal style. Perhaps I'm missing something, but I like to write a ton of assertions to validate code invariants. On assertion failure, which obviously never happens as I write perfect code that never violates invariants, all I want to happen is 'write the error in the logs and return 50x'. I suppose panic/recover is the way to go, but I have the impression they are shunned by the community and not recommended by Golang official docs. https://golang.org/doc/faq#assertions https://golang.org/doc/faq#assertions > Why does Go not have assertions? > Go doesn't provide assertions. They are undeniably convenient, but our experience has been that programmers use them as a crutch to avoid thinking about proper error handling and reporting. Proper error handling means that servers continue to operate instead of crashing after a non-fatal error. Proper error reporting means that errors are direct and to the point, saving the programmer from interpreting a large crash trace. Precise errors are particularly important when the programmer seeing the errors is not familiar with the code. > We understand that this is a point of contention. There are many things in the Go language and libraries that differ from modern practices, simply because we feel it's sometimes worth trying a different approach.
Smaug123 6y ago
Well, the point is not that "handle errors immediately" is bad. It's that "tuples are a poor way to do it". A Result type makes you handle errors immediately, but also precisely models what you need (i.e. you don't even get the choice to use an invalid returned value).

alquemist 6y ago

Granted, explicit error handling is a good idea. At some level, it depends on the personal style. Perhaps I'm missing something, but I like to write a ton of assertions to validate code invariants. On assertion failure, which obviously never happens as I write perfect code that never violates invariants, all I want to happen is 'write the error in the logs and return 50x'. I suppose panic/recover is the way to go, but I have the impression they are shunned by the community and not recommended by Golang official docs. https://golang.org/doc/faq#assertions https://golang.org/doc/faq#assertions > Why does Go not have assertions? > Go doesn't provide assertions. They are undeniably convenient, but our experience has been that programmers use them as a crutch to avoid thinking about proper error handling and reporting. Proper error handling means that servers continue to operate instead of crashing after a non-fatal error. Proper error reporting means that errors are direct and to the point, saving the programmer from interpreting a large crash trace. Precise errors are particularly important when the programmer seeing the errors is not familiar with the code. > We understand that this is a point of contention. There are many things in the Go language and libraries that differ from modern practices, simply because we feel it's sometimes worth trying a different approach.

Smaug123 6y ago

Well, the point is not that "handle errors immediately" is bad. It's that "tuples are a poor way to do it". A Result type makes you handle errors immediately, but also precisely models what you need (i.e. you don't even get the choice to use an invalid returned value).