6 ms·

If you're writing a command line utility that tries to load a config file and falls back on defaults if it's not found, you may try to load it and just ignore a

If you're writing a command line utility that tries to load a config file and falls back on defaults if it's not found, you may try to load it and just ignore any error, only caring that it either returns a path if found or null if you should use default values.

dwaite 8y ago
I believe what you are saying is that you can ignore errors if you check or rely on the side effects of an error (such as the result of a function being null on error). One could argue that the side effect is part of the error, and really what you are ignoring are the details of an error (e.g. did the config entry fail to load because the config file wasn't found, because of filesystem permissions, or because the particular configuration key wasn't present?)
- sephware 8y ago
  That's a good way to put it, and yeah I would agree that's how I like to use errors: give me the details I ask for and let me ignore the ones I don't care about. Sometimes an "error" isn't really an error, and at those times exceptions are overkill. Sometimes an error really is an error and I need to let the user know something went wrong, give them enough details to let them fix it and wait for them to try again.
Skunkleton 8y ago
But wouldn't that look like: var s Settings if s, err := load_settings(); err != nil { s = defaults() } Where is the unhandled error?
- TheDong 8y ago
  Note that your code will not work; you've shadowed 's' inside the if block because you have 'if s, err := ...'. As a result, 's = defaults()' will set the shadowed 's' variable that only exists within the if block to defaults, but the 'var s Settings' you declared above will not be modified. Here's a playground showing the issue: https://play.golang.org/p/eE0HEZx1MJu https://play.golang.org/p/eE0HEZx1MJu Go is full of nice little foot-guns like that :) You would want to also have 'var err error' above the block and use '=' instead of ':=' to fix this sort of issue.
  - Skunkleton 8y ago
    I am by no means an expert (or even a frequent user) of go. However, the most unfortunate foot cannon I have encountered is this: package main type HowOdd interface { Poke() string } type AConcreteThing struct { } func (t *AConcreteThing) Poke() string { return "hehe" } func DoAConcreteThing() *AConcreteThing { return nil } func DoAThing() HowOdd { return DoAConcreteThing() } func main() { lolWhat := DoAThing() if lolWhat != nil { panic("How could this happen?") } } I understand that the interface at the bottom is a non-null interface containing a null value, but...damn, that sucks.

dwaite 8y ago

I believe what you are saying is that you can ignore errors if you check or rely on the side effects of an error (such as the result of a function being null on error). One could argue that the side effect is part of the error, and really what you are ignoring are the details of an error (e.g. did the config entry fail to load because the config file wasn't found, because of filesystem permissions, or because the particular configuration key wasn't present?)

sephware 8y ago
That's a good way to put it, and yeah I would agree that's how I like to use errors: give me the details I ask for and let me ignore the ones I don't care about. Sometimes an "error" isn't really an error, and at those times exceptions are overkill. Sometimes an error really is an error and I need to let the user know something went wrong, give them enough details to let them fix it and wait for them to try again.

Skunkleton 8y ago

But wouldn't that look like: var s Settings if s, err := load_settings(); err != nil { s = defaults() } Where is the unhandled error?

TheDong 8y ago
Note that your code will not work; you've shadowed 's' inside the if block because you have 'if s, err := ...'. As a result, 's = defaults()' will set the shadowed 's' variable that only exists within the if block to defaults, but the 'var s Settings' you declared above will not be modified. Here's a playground showing the issue: https://play.golang.org/p/eE0HEZx1MJu https://play.golang.org/p/eE0HEZx1MJu Go is full of nice little foot-guns like that :) You would want to also have 'var err error' above the block and use '=' instead of ':=' to fix this sort of issue.
- Skunkleton 8y ago
  I am by no means an expert (or even a frequent user) of go. However, the most unfortunate foot cannon I have encountered is this: package main type HowOdd interface { Poke() string } type AConcreteThing struct { } func (t *AConcreteThing) Poke() string { return "hehe" } func DoAConcreteThing() *AConcreteThing { return nil } func DoAThing() HowOdd { return DoAConcreteThing() } func main() { lolWhat := DoAThing() if lolWhat != nil { panic("How could this happen?") } } I understand that the interface at the bottom is a non-null interface containing a null value, but...damn, that sucks.