14 ms·

Please indulge an ignorant question from a Go-curious outsider: are ignored error returns flagged/grumbled-about? One of the enduring PITAs with C-error handlin

Please indulge an ignorant question from a Go-curious outsider: are ignored error returns flagged/grumbled-about? One of the enduring PITAs with C-error handling is that AFAIK there's no good way to highlight slipshod code. For example printf() returns "int number_chars_written", system() returns "int status_code": ignoring the first case is ubiquitous and having to cast it to (void) is noisy, ignoring the second is a bad smell and warrants at least a comment. How does this compare to error handling in Go?

usrbinbash 4y ago
> are ignored error returns flagged/grumbled-about? No, they are not. func couldFail() error { /*...*/ } func ohNoes() { couldFail() } ohNoes() can call couldFail() and ignore the error return completely, without the compiler complaining. This is intended. Error returns are not special; they are just another return value. Error handling by the caller includes "I don't care if there is an error". Yes, in some situations that's a bad code smell. In others, it really doesn't matter. Go puts the responsibility to decide which applies in the hands of the programmer. To get the same effect in python, I'd have to wrap the call in try: couldFail() except: pass
- jenny91 4y ago
  I'd hope it's a pretty non-controversial thing by now that software shouldn't silently fail without indicating something's wrong? If I saw the latter Python code in a code review I would squirm. I would scrutinize it very seriously and if there's some really odd case where you really want this, I'd require at least a logger line or a comment to explain why in the world this is desired behavior.
  - usrbinbash 4y ago
    > I'd hope it's a pretty non-controversial thing by now that software shouldn't silently fail without indicating something's wrong? That depends whether the error condition is worth caring about, for a given application, in a given state. eg. how often do programs check if `printf("something")` actually succeeded?
    - jenny91 4y ago
      > eg. how often do programs check if `printf("something")` actually succeeded? Probably not very often? But they probably should? If you're printing something, there's probably a case where you care about that being printed, and if it's not in that case, that's bad? This also applies to logs too. Just because you're not always looking at the logs doesn't mean they're not important when you need them. Sure, if you have some chatty logs going through a distributed logging system you might not want to crash the whole thing, and in that case you might want to ignore the exception. But this is a very fringe case.
      - deleted 4y ago
        [deleted]

usrbinbash 4y ago

> are ignored error returns flagged/grumbled-about? No, they are not. func couldFail() error { /*...*/ } func ohNoes() { couldFail() } ohNoes() can call couldFail() and ignore the error return completely, without the compiler complaining. This is intended. Error returns are not special; they are just another return value. Error handling by the caller includes "I don't care if there is an error". Yes, in some situations that's a bad code smell. In others, it really doesn't matter. Go puts the responsibility to decide which applies in the hands of the programmer. To get the same effect in python, I'd have to wrap the call in try: couldFail() except: pass

jenny91 4y ago
I'd hope it's a pretty non-controversial thing by now that software shouldn't silently fail without indicating something's wrong? If I saw the latter Python code in a code review I would squirm. I would scrutinize it very seriously and if there's some really odd case where you really want this, I'd require at least a logger line or a comment to explain why in the world this is desired behavior.
- usrbinbash 4y ago
  > I'd hope it's a pretty non-controversial thing by now that software shouldn't silently fail without indicating something's wrong? That depends whether the error condition is worth caring about, for a given application, in a given state. eg. how often do programs check if `printf("something")` actually succeeded?
  - jenny91 4y ago
    > eg. how often do programs check if `printf("something")` actually succeeded? Probably not very often? But they probably should? If you're printing something, there's probably a case where you care about that being printed, and if it's not in that case, that's bad? This also applies to logs too. Just because you're not always looking at the logs doesn't mean they're not important when you need them. Sure, if you have some chatty logs going through a distributed logging system you might not want to crash the whole thing, and in that case you might want to ignore the exception. But this is a very fringe case.
    - deleted 4y ago
      [deleted]