3 ms·

Once I got used to it I found I kind of like the Go paradigm of checking for errors every time something could go wrong, and (usually) passing the first one up

by biztos 10y ago

Once I got used to it I found I kind of like the Go paradigm of checking for errors every time something could go wrong, and (usually) passing the first one up the chain with some additional context info. However, the fact that "ignore error" is an easy and built-in paradigm that even shows up in the official docs: fragileThing, _ := scary.MightNotWork() that fills me with dread.

woah 10y ago
I think that's in the docs mostly for conciseness. I don't think anyone thinks that it's a good practice in real code.
- aikah 10y ago
  So you admit Go error as value is verbose. Because they are. The best system ihmo is Java's. If a method throws then IT should be part of the method signature and dealing with the error (try/catch) should be mandatory. The irony is that Go has some form of (inferior) try/catch with panic/recover. So it has both but still pretends exceptions are bad.
  - jerf 10y ago
    The problem with checked exceptions is nothing more and nothing less than they didn't work. Yes, in theory, or at least some theories, checked exceptions ought to be awesome. But they aren't in practice. Go's error handling in practice works better than Java checked exceptions. Where fact and theory conflict, fact wins. (I emphasize "checked" because there is a much more robust and interesting discussion about exceptions in general, and then of course a number of sidecar discussions about other error handling mechanisms like Either/Option, etc. I'm only making this claim about checked exceptions. Which is kinda shooting fish in a barrel; arguably C's error handling worked better than Java's checked exceptions and I think C's "error handling" isn't even worthy of the term.)
Ntrails 10y ago
Could you elaborate? Assuming that scary.MightNotWork() is some kind of ancillary function that is non-essential, why would I want to let it impact the main program. The example that comes to mind would be logging. If I have set up my own "Write logs into network share" call, I'd never ever expect it to throw errors that took down the app. Share down? Don't care. logfile locked/corrupt. Don't care. Try and log, if you can't, fail silently without impacting the main purpose of the application/service/whatever.
- iotscale 10y ago
  > Try and log, if you can't, fail silently without impacting the main purpose of the application/service/whatever. Are you being serious? I agree that there can be "some kind of ancillary function that is non-essential" but in the case of failed logging you should try sending an email / showing some warning if you have a GUI / try other outputs / crash with a meaningful error especially if you are running under some sort of supervisor... etc. Of course that doesn't invalidate your main point.
- biztos 10y ago
  Sure. If your function does things internally that might return errors, the normal thing to do is have your function also potentially return an error, namely the first error it finds. If you call a function the error of which isn't a big deal to your function, you'd normally check the return value to make sure it meets your expectations. If it does, fine -- proceed accordingly. If it doesn't, then send the error up the chain. So -- totally bogus example -- say you want to return the mod time of a file or, if the file doesn't exist, the epoch. The file not existing is an error, but not one you'd abort on; other file errors though would be problematic: // ModOrEpoch returns the modification time of the file at path, or the epoch // time if there is no such file. Unexpected file conditions are returned // as errors. func ModOrEpoch(path string) (time.Time, error) { epoch := time.Unix(0, 0) info, err := os.Stat(path) if err != nil { if os.IsNotExist(err) { return epoch, nil } return time.Now(), fmt.Errorf("File error for %s: %s", path, err.Error()) } if info.IsDir() { return time.Now(), fmt.Errorf("File is a directory: %s", path) } return info.ModTime(), nil } https://play.golang.org/p/AMSJMV3tks https://play.golang.org/p/AMSJMV3tks I suppose it's possible you might really, really not care about an error, but that would be extremely un-idiomatic in Go. And, I would argue, a very bad habit in any language where the error could possibly be other than what you expect; sort of like try { foobar(); } catch(e) { /* global thermonuclear war? */ } The thing that bugs me about seeing the errors ignored in official docs is that the Go world puts a lot of emphasis on writing idiomatic code, and the Go "idiom" is much less flexible than, say, Perl's. You might reasonably look to the official documentation to learn what is and isn't idiomatic. And you would hopefully figure out soon enough that ignoring errors isn't, but then again you might not.

by biztos 10y ago

woah 10y ago

I think that's in the docs mostly for conciseness. I don't think anyone thinks that it's a good practice in real code.

aikah 10y ago
So you admit Go error as value is verbose. Because they are. The best system ihmo is Java's. If a method throws then IT should be part of the method signature and dealing with the error (try/catch) should be mandatory. The irony is that Go has some form of (inferior) try/catch with panic/recover. So it has both but still pretends exceptions are bad.
- jerf 10y ago
  The problem with checked exceptions is nothing more and nothing less than they didn't work. Yes, in theory, or at least some theories, checked exceptions ought to be awesome. But they aren't in practice. Go's error handling in practice works better than Java checked exceptions. Where fact and theory conflict, fact wins. (I emphasize "checked" because there is a much more robust and interesting discussion about exceptions in general, and then of course a number of sidecar discussions about other error handling mechanisms like Either/Option, etc. I'm only making this claim about checked exceptions. Which is kinda shooting fish in a barrel; arguably C's error handling worked better than Java's checked exceptions and I think C's "error handling" isn't even worthy of the term.)

Ntrails 10y ago

Could you elaborate? Assuming that scary.MightNotWork() is some kind of ancillary function that is non-essential, why would I want to let it impact the main program. The example that comes to mind would be logging. If I have set up my own "Write logs into network share" call, I'd never ever expect it to throw errors that took down the app. Share down? Don't care. logfile locked/corrupt. Don't care. Try and log, if you can't, fail silently without impacting the main purpose of the application/service/whatever.

iotscale 10y ago
> Try and log, if you can't, fail silently without impacting the main purpose of the application/service/whatever. Are you being serious? I agree that there can be "some kind of ancillary function that is non-essential" but in the case of failed logging you should try sending an email / showing some warning if you have a GUI / try other outputs / crash with a meaningful error especially if you are running under some sort of supervisor... etc. Of course that doesn't invalidate your main point.
biztos 10y ago
Sure. If your function does things internally that might return errors, the normal thing to do is have your function also potentially return an error, namely the first error it finds. If you call a function the error of which isn't a big deal to your function, you'd normally check the return value to make sure it meets your expectations. If it does, fine -- proceed accordingly. If it doesn't, then send the error up the chain. So -- totally bogus example -- say you want to return the mod time of a file or, if the file doesn't exist, the epoch. The file not existing is an error, but not one you'd abort on; other file errors though would be problematic: // ModOrEpoch returns the modification time of the file at path, or the epoch // time if there is no such file. Unexpected file conditions are returned // as errors. func ModOrEpoch(path string) (time.Time, error) { epoch := time.Unix(0, 0) info, err := os.Stat(path) if err != nil { if os.IsNotExist(err) { return epoch, nil } return time.Now(), fmt.Errorf("File error for %s: %s", path, err.Error()) } if info.IsDir() { return time.Now(), fmt.Errorf("File is a directory: %s", path) } return info.ModTime(), nil } https://play.golang.org/p/AMSJMV3tks https://play.golang.org/p/AMSJMV3tks I suppose it's possible you might really, really not care about an error, but that would be extremely un-idiomatic in Go. And, I would argue, a very bad habit in any language where the error could possibly be other than what you expect; sort of like try { foobar(); } catch(e) { /* global thermonuclear war? */ } The thing that bugs me about seeing the errors ignored in official docs is that the Go world puts a lot of emphasis on writing idiomatic code, and the Go "idiom" is much less flexible than, say, Perl's. You might reasonably look to the official documentation to learn what is and isn't idiomatic. And you would hopefully figure out soon enough that ignoring errors isn't, but then again you might not.