4 ms·

"Always handle errors" sounds good until you remember that every read or write can potentially fail. My go programs are littered with unchecked fmt.Printf or Pr

"Always handle errors" sounds good until you remember that every read or write can potentially fail. My go programs are littered with unchecked fmt.Printf or Println statements.

BobbyJo 3y ago
That seems like the kind of thing you'd want to wrap and panic on rather than ignore. If fmt.Print doesn't work, you should probably just kill the process.
- comex 3y ago
  That has the downside that if the user pipes your program’s standard output to, say, `head`, then once `head` is done reading the first few lines and exits, the program will blow up and probably print a message to standard error that clutters the user’s terminal (where they were expecting to see the first few lines of output). Though, continuing to spend time generating more output that goes nowhere may not be particularly useful either, depending on what the program does. Still I think ignoring errors writing to stdout is better as a general default. If nothing else, it’s the most common behavior and is thus more likely to fit the user’s expectations.
preseinger 3y ago
fmt.Printf failures are un-actionable, so there's no reason to handle them
- tgv 3y ago
  That's what the parent comment means, I think.
  - incompatible 3y ago
    I didn't mean anything in particular, I just made an observation. I feel bad for having all those unchecked error returns. I wouldn't want to wrap them in a panic, especially if it was some kind of server. Actually, I'm reminded of certain errors I've seen along the lines of "exception raised while handing exception".
    - preseinger 3y ago
      the question is: does it matter if a given expression fails? if so, get the error and evaluate it -- like if json.Marshal fails in your http.Handler if not, (shrug) -- like (maybe) if your fmt.Printf fails panics are for core assertion violations, not an ersatz error reporting mechanism

"Always handle errors" sounds good until you remember that every read or write can potentially fail. My go programs are littered with unchecked fmt.Printf or Println statements.

BobbyJo 3y ago

That seems like the kind of thing you'd want to wrap and panic on rather than ignore. If fmt.Print doesn't work, you should probably just kill the process.

comex 3y ago
That has the downside that if the user pipes your program’s standard output to, say, `head`, then once `head` is done reading the first few lines and exits, the program will blow up and probably print a message to standard error that clutters the user’s terminal (where they were expecting to see the first few lines of output). Though, continuing to spend time generating more output that goes nowhere may not be particularly useful either, depending on what the program does. Still I think ignoring errors writing to stdout is better as a general default. If nothing else, it’s the most common behavior and is thus more likely to fit the user’s expectations.

preseinger 3y ago

fmt.Printf failures are un-actionable, so there's no reason to handle them

tgv 3y ago
That's what the parent comment means, I think.
- incompatible 3y ago
  I didn't mean anything in particular, I just made an observation. I feel bad for having all those unchecked error returns. I wouldn't want to wrap them in a panic, especially if it was some kind of server. Actually, I'm reminded of certain errors I've seen along the lines of "exception raised while handing exception".
  - preseinger 3y ago
    the question is: does it matter if a given expression fails? if so, get the error and evaluate it -- like if json.Marshal fails in your http.Handler if not, (shrug) -- like (maybe) if your fmt.Printf fails panics are for core assertion violations, not an ersatz error reporting mechanism