4 ms·
> functions which are known to never be checked for their errors, like fmt.Println In Java println is checked for errors, as it should be. Every Java program
by bsdetector 10y ago
> functions which are known to never be checked for their errors, like fmt.Println
In Java println is checked for errors, as it should be. Every Java program that does println either aborts or deals with the error in some way.
It matters. Take any program that writes to stdout and run it with ">&-" to close stdout. Because of unix, the next file it opens will be file descriptor 1 and the program will start writing the console output to the file. You want the program to abort instead of trashing a file, and especially not to trash /etc/passwd.
That's why you don't want to ignore errors, because any time you do there can be unintended and hard to imagine consequences -- even something as simple as writing to the console. Simply put, Go encourages buggy programs with poor error handling.
- AnimalMuppet 10y agoAnd the cynic in me says that, if you do that with a program that handles the password file, you almost deserve what you're going to get...
- echlebek 10y agoI tried your example, and observed an error: write /dev/stdout: bad file descriptor What "next file it opens" are you talking about exactly? How does what you're describing work?
- bsdetector 10y agoIn unix when you open a file it gets the lowest available file descriptor number. So if you run a program with no stdout (file descriptor 1) then it gets a "bad file descriptor" error anytime it prints something until a file is opened, gets file descriptor 1, then it starts writing to the file. Example: #include <stdio.h> int main(int argc, char **argv) { printf("first message\n"); fflush(stdout); fopen("output", "w"); printf("second message\n"); fflush(stdout); } Output: # ./a.out first message second message # ./a.out 1>&- # cat output second message By ignoring the error, the program continued on and then wrote console output messages to the file after it was opened. There have been exploits due to this bug, but the real point is that you could never predict this failure without good knowledge of unix and careful consideration. This is why error codes should not be cavalierly ignored, because it's really hard to know what might happen if you do. Last I checked, Go operates the same way as this C example. Java fails on the "first message" if stdout is closed so it doesn't trash the file, not because they even specifically thought of this scenario but just because errors are not ignored by default and are not easy to ignore.