4 ms·

Incidentally, your link includes a great example of Go's error handling - which is inevitably what actually happens in languages without exceptions: errors are

by _yosefk 12y ago

Incidentally, your link includes a great example of Go's error handling - which is inevitably what actually happens in languages without exceptions: errors are silenced and the program marches on, each step making less sense than the previous. It's a good talking point that you can always check error values - but it never really happens, in part because library designers try to avoid putting the burden on themselves and their users: "Getenv returns the empty string and continues. Then Go somehow manages to parse the empty string as an empty JSON list and still continues. Then it tries to interpret the first of the user arguments to the program as the path of the program to run and execs that instead! Utter failure." I happened to write about it just before Go came out here: http://yosefk.com/blog/what-makes-cover-up-preferable-to-error-handling.html http://yosefk.com/blog/what-makes-cover-up-preferable-to-err... It seems that having exceptions in the language is a great predictor for libraries/built-ins barfing upon bad input vs silently producing garbage (as in JS's "undefined" string produced from undefined values and propagated, or Go's behavior above, etc.) For instance Lisp's NTH produces garbage and it predates Lisp's exception handling features whereas AREF was added later and indeed complains loudly, etc.

enneff 12y ago
The hundreds of high quality Go packages that do handle errors are an existence proof against your argument. Look at nearly anything on godoc.org. You didn't cite that quote. I am certain whoever said it is doing something silly.
- _yosefk 12y ago
  I did cite it - it's from my parent comment's link: http://roscidus.com/blog/blog/2013/06/09/choosing-a-python-replacement-for-0install/ http://roscidus.com/blog/blog/2013/06/09/choosing-a-python-r... Are you saying that: * Getenv doesn't return an empty string for a non-existent env var? * Go JSON parser doesn't return an empty list given an empty string? That you can handle errors without exceptions needn't have an existence proof... The question is how many errors are silenced. Stats will be hard to come by. But getenv and JSON parsing are pretty basic functionality and in most languages with exceptions they would not silence errors. (say, Python's json.loads barfs and os.getenv returns None which unlike the empty string will almost certainly lead to an exception if the code won't account for None). So it's a good anecdote in the absence of hard data.
  - bsdetector 12y ago
    And here I thought you were talking about the first example in the blog: fmt.Println("Hello, world") Now what happens when program opens a file and is run without stdout: ./program >&- The file it opens is fd 1 and the program prints to the file instead of printing to the console. An odd case that has caused security holes in the past. In languages that fail on errors if they print anything before opening the file then they don't corrupt the file. The default and laziest case for errors should never be to just hide them and continue on.
  - tuxychandru 12y ago
    JSON parser does return an error on empty string. http://play.golang.org/p/DE0soRRRBp http://play.golang.org/p/DE0soRRRBp
    - skj 12y ago
      Bam!
    - flaie 12y ago
      If you use a `Decoder` instead you can check for the `io.EOF` error in that case. http://play.golang.org/p/cbWe9se76d http://play.golang.org/p/cbWe9se76d
  - enneff 12y ago
    Sorry, I missed the blog post. The Go code in the post is garbage. It doesn't check errors, which all good Go code does. (His plan to "add error handling only if the compiler told [him] to" is a bad idea.) I talk about the Go philosophy of error handling here: https://www.youtube.com/watch?v=dKGmK_Z1Zl0#t=27m10s https://www.youtube.com/watch?v=dKGmK_Z1Zl0#t=27m10s json.Unmarshal only returns an error value, so it never "returns an empty list". Instead you provide it with a []byte of the JSON data you want decoded and a pointer to the data structure into which to put the decoded data. If you don't check the error value returned by json.Unmarshal then you don't know if it decoded anything or not. That's why the author is left with an empty list. In reality you'd add two lines to get the following code, which does not proceed past the failure in json.Unmarshal: http://play.golang.org/p/rYfwncjU2f http://play.golang.org/p/rYfwncjU2f An aside: os.Getenv doesn't return an error value because it's a convenience that is mostly used in contexts where you don't care if the variable is set or not (in the shell you usually don't care either, you just test for != ""). If you actually care you can inspect the environment with os.Environ. But in this case it doesn't matter.
jzelinskie 12y ago
I could get behind the Go compiler to forcing people to write "_ = errReturningFunc()" instead of simply "errReturningFunc()" if they want to explicitly ignore errors. In my recent experience, it actually bothers me a lot that funcs in the standard library would often rather return nil or the zero-value of a type than change the signature of the func to return (T, err). I don't really care that the docs describe that behavior -- that behavior is an error.
- _yosefk 12y ago
  The thing is, compilers can force people to refer to error variables, but they can't prevent people from returning array[0] when i is out of array[]'s bounds, an empty list given an empty JSON string, etc. And forcing the former unfortunately only encourages the latter.
- fauigerzigerk 12y ago
  Returning (T, err) means that the function cannot be used as part of a larger expression. That's the main issue with this idiom in my view.
  - NateDad 12y ago
    This is a feature. The statement might not succeed. You shouldn't use it as part of a bigger expression and assume it will work. t, err := foo() if err != nil { return err } bar(t) this makes it totally clear that foo can fail, and if it does, then we won't call bar. In languages with exceptions, this line just looks like bar(foo()) And then you can't tell that foo might fail and we might not call bar. Even if you wrap the whole thing in a try/catch, it's not clear. This is why exceptions are an anti-pattern. They hide what functions can fail and what happens when they do.
fauigerzigerk 12y ago
>It seems that having exceptions in the language is a great predictor for libraries/built-ins barfing upon bad input vs silently producing garbage Maybe so, but having exceptions in a language is also a good predictor for the misuse of exceptions for purposes other than error handling. For instance, Python has the StopIteration exception to signal the end of an iteration. Exceptions force API designers to decide whether or not a situation is exceptional enough to force a stack unwind on the caller's end. That's not something that's necessarily decidable from the point of view of the library. For instance, say you have a function http.get(url). Should a 404 response automatically raise an exception? What about a 301? A network issue? Surely, for a crawler, a 404 is not exceptional enough to merit a hidden goto that unwinds the stack frame (by default). The designer of the http library cannot decide which status code is exceptional in every application. It's similar with the results of SQL statements, file system access and all sorts of other IO related stuff. It seems to me that the more complex a system is, the more it needs a very specific error handling strategy anyway and doesn't benefit from library designers' opinions about what is and isn't worth a stack unwind. That said, I do hate seeing if err != nil { return nil, err } on every other line of code.
- marcosdumay 12y ago
  > Maybe so, but having exceptions in a language is also a good predictor for the misuse of exceptions for purposes other than error handling. Is that really a problem? I once hated such uses, but could never point why.
  - fauigerzigerk 12y ago
    I think it's a problem for two reasons: First of all, sudden stack unwind comes with a greater mental burden than regular structured code. Something implicit is happening that violates the expectations we have based on what we can see. Secondly, consistency is always important because inconsistency forces us to think about things that we shouldn't have to think about, which lowers our productivity.
- p0nce 12y ago
  Don't worry, you won't see them that much since people will forget them. That's the entire point of exceptions: never let an error get silenced.

by _yosefk 12y ago

enneff 12y ago

The hundreds of high quality Go packages that do handle errors are an existence proof against your argument. Look at nearly anything on godoc.org. You didn't cite that quote. I am certain whoever said it is doing something silly.

_yosefk 12y ago
I did cite it - it's from my parent comment's link: http://roscidus.com/blog/blog/2013/06/09/choosing-a-python-replacement-for-0install/ http://roscidus.com/blog/blog/2013/06/09/choosing-a-python-r... Are you saying that: * Getenv doesn't return an empty string for a non-existent env var? * Go JSON parser doesn't return an empty list given an empty string? That you can handle errors without exceptions needn't have an existence proof... The question is how many errors are silenced. Stats will be hard to come by. But getenv and JSON parsing are pretty basic functionality and in most languages with exceptions they would not silence errors. (say, Python's json.loads barfs and os.getenv returns None which unlike the empty string will almost certainly lead to an exception if the code won't account for None). So it's a good anecdote in the absence of hard data.
- bsdetector 12y ago
  And here I thought you were talking about the first example in the blog: fmt.Println("Hello, world") Now what happens when program opens a file and is run without stdout: ./program >&- The file it opens is fd 1 and the program prints to the file instead of printing to the console. An odd case that has caused security holes in the past. In languages that fail on errors if they print anything before opening the file then they don't corrupt the file. The default and laziest case for errors should never be to just hide them and continue on.
- tuxychandru 12y ago
  JSON parser does return an error on empty string. http://play.golang.org/p/DE0soRRRBp http://play.golang.org/p/DE0soRRRBp
  - skj 12y ago
    Bam!
  - flaie 12y ago
    If you use a `Decoder` instead you can check for the `io.EOF` error in that case. http://play.golang.org/p/cbWe9se76d http://play.golang.org/p/cbWe9se76d
- enneff 12y ago
  Sorry, I missed the blog post. The Go code in the post is garbage. It doesn't check errors, which all good Go code does. (His plan to "add error handling only if the compiler told [him] to" is a bad idea.) I talk about the Go philosophy of error handling here: https://www.youtube.com/watch?v=dKGmK_Z1Zl0#t=27m10s https://www.youtube.com/watch?v=dKGmK_Z1Zl0#t=27m10s json.Unmarshal only returns an error value, so it never "returns an empty list". Instead you provide it with a []byte of the JSON data you want decoded and a pointer to the data structure into which to put the decoded data. If you don't check the error value returned by json.Unmarshal then you don't know if it decoded anything or not. That's why the author is left with an empty list. In reality you'd add two lines to get the following code, which does not proceed past the failure in json.Unmarshal: http://play.golang.org/p/rYfwncjU2f http://play.golang.org/p/rYfwncjU2f An aside: os.Getenv doesn't return an error value because it's a convenience that is mostly used in contexts where you don't care if the variable is set or not (in the shell you usually don't care either, you just test for != ""). If you actually care you can inspect the environment with os.Environ. But in this case it doesn't matter.

jzelinskie 12y ago

I could get behind the Go compiler to forcing people to write "_ = errReturningFunc()" instead of simply "errReturningFunc()" if they want to explicitly ignore errors. In my recent experience, it actually bothers me a lot that funcs in the standard library would often rather return nil or the zero-value of a type than change the signature of the func to return (T, err). I don't really care that the docs describe that behavior -- that behavior is an error.

_yosefk 12y ago
The thing is, compilers can force people to refer to error variables, but they can't prevent people from returning array[0] when i is out of array[]'s bounds, an empty list given an empty JSON string, etc. And forcing the former unfortunately only encourages the latter.
fauigerzigerk 12y ago
Returning (T, err) means that the function cannot be used as part of a larger expression. That's the main issue with this idiom in my view.
- NateDad 12y ago
  This is a feature. The statement might not succeed. You shouldn't use it as part of a bigger expression and assume it will work. t, err := foo() if err != nil { return err } bar(t) this makes it totally clear that foo can fail, and if it does, then we won't call bar. In languages with exceptions, this line just looks like bar(foo()) And then you can't tell that foo might fail and we might not call bar. Even if you wrap the whole thing in a try/catch, it's not clear. This is why exceptions are an anti-pattern. They hide what functions can fail and what happens when they do.

fauigerzigerk 12y ago

>It seems that having exceptions in the language is a great predictor for libraries/built-ins barfing upon bad input vs silently producing garbage Maybe so, but having exceptions in a language is also a good predictor for the misuse of exceptions for purposes other than error handling. For instance, Python has the StopIteration exception to signal the end of an iteration. Exceptions force API designers to decide whether or not a situation is exceptional enough to force a stack unwind on the caller's end. That's not something that's necessarily decidable from the point of view of the library. For instance, say you have a function http.get(url). Should a 404 response automatically raise an exception? What about a 301? A network issue? Surely, for a crawler, a 404 is not exceptional enough to merit a hidden goto that unwinds the stack frame (by default). The designer of the http library cannot decide which status code is exceptional in every application. It's similar with the results of SQL statements, file system access and all sorts of other IO related stuff. It seems to me that the more complex a system is, the more it needs a very specific error handling strategy anyway and doesn't benefit from library designers' opinions about what is and isn't worth a stack unwind. That said, I do hate seeing if err != nil { return nil, err } on every other line of code.

marcosdumay 12y ago
> Maybe so, but having exceptions in a language is also a good predictor for the misuse of exceptions for purposes other than error handling. Is that really a problem? I once hated such uses, but could never point why.
- fauigerzigerk 12y ago
  I think it's a problem for two reasons: First of all, sudden stack unwind comes with a greater mental burden than regular structured code. Something implicit is happening that violates the expectations we have based on what we can see. Secondly, consistency is always important because inconsistency forces us to think about things that we shouldn't have to think about, which lowers our productivity.
p0nce 12y ago
Don't worry, you won't see them that much since people will forget them. That's the entire point of exceptions: never let an error get silenced.