3 ms·

a isn't necessarily the case. Consider fmt.Println: func Println(a ...interface{}) (n int, err error) I've never seen any code that handled err -- I don't mean

by khyryk 13y ago

a isn't necessarily the case. Consider fmt.Println: func Println(a ...interface{}) (n int, err error) I've never seen any code that handled err -- I don't mean ignoring it with _, I mean not even acknowledging its existence -- without the compiler saying anything.

dilap 13y ago
Yeah, but if print fails, what are you going to do? And it's not like ignoring this error is going to make your code blow up.
- 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 ago
    Don'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 ago
      How 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.
- apw 13y ago
  If your program is expected to operate in a pipeline, as most UNIX programs are, shouldn't you always check for printf returning an error? For example: yourprogram | head -100
  - dilap 13y ago
    I'm not sure, actually, what's the proper way to do it? For fun, I wrote three programs that just print 1 2 3 ... to stdout forever, in python, go, and plain c. None do any error checking. Here's the results: $ py printcount.py | head -10 1 2 3 4 5 6 7 8 9 10 Traceback (most recent call last): File "printcount.py", line 3, in <module> print i IOError: [Errno 32] Broken pipe $ go run printcount.go | head -10 1 2 3 4 5 6 7 8 9 10 signal: broken pipe $ ./printcount | head -10 1 2 3 4 5 6 7 8 9 10 $ pgrep printcount $ Interestingly enough, only plain old C actually did what I wanted here. In Go and Python, we'd have to do a little work to not print the annoying error. But I don't think we want to check return codes from print in any of the languages.

by khyryk 13y ago

dilap 13y ago

Yeah, but if print fails, what are you going to do? And it's not like ignoring this error is going to make your code blow up.

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 ago
  Don'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 ago
    How 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.
apw 13y ago
If your program is expected to operate in a pipeline, as most UNIX programs are, shouldn't you always check for printf returning an error? For example: yourprogram | head -100
- dilap 13y ago
  I'm not sure, actually, what's the proper way to do it? For fun, I wrote three programs that just print 1 2 3 ... to stdout forever, in python, go, and plain c. None do any error checking. Here's the results: $ py printcount.py | head -10 1 2 3 4 5 6 7 8 9 10 Traceback (most recent call last): File "printcount.py", line 3, in <module> print i IOError: [Errno 32] Broken pipe $ go run printcount.go | head -10 1 2 3 4 5 6 7 8 9 10 signal: broken pipe $ ./printcount | head -10 1 2 3 4 5 6 7 8 9 10 $ pgrep printcount $ Interestingly enough, only plain old C actually did what I wanted here. In Go and Python, we'd have to do a little work to not print the annoying error. But I don't think we want to check return codes from print in any of the languages.