4 ms·
The point is that I can't immediately tell which errors will be mysteriously ignored. This, together with the existence of panics, undermines the stance that on
by khyryk 13y ago
The point is that I can't immediately tell which errors will be mysteriously ignored. This, together with the existence of panics, undermines the stance that one can tell exactly what a certain piece of Go code will do just by looking at, say, a function prototype.
- cmccabe 13y agoDon't be fatuous. If you wrote all of the code, you should be able to tell exactly what it does. If there's some code you're calling that was written by someone else, you have to trust it to do the right thing. Exceptions versus return codes doesn't change that fact. People usually don't check the return code of fmt.Printf because they simply don't care. Most of the time, you're just logging to a terminal, which basically never fails. And if logging did fail, you wouldn't want to abort the program because of it. The only time you might want to check the return value of printf is if you're writing a simple utility designed to transform something passed on stdin to something on stdout.
- khyryk 13y agoHow am I being fatuous? It is obviously false that there is any sort of guarantee that errors have to be dealt with if the compiler allows some indeterminate number of functions (unless there's a list somewhere) to be exceptions to the rule.