Comment by _yosefk | Hacker News Reader

Comment by _yosefk | Hacker News Reader

Parent Full thread

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-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.

>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.

> 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.

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.

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.

Haha, no. You pretty much never forget them. And if you're worried, you can run a linter to find spots you've missed.

My go programs are 100x as robust as my programs with exceptions because Go actually forces you to think about the error path, not just the good path.

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.

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.

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.

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.

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.

I did cite it - it's from my parent comment's link: 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.

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

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

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.

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.

JSON parser does return an error on empty string.

http://play.golang.org/p/DE0soRRRBp

If you use a `Decoder` instead you can check for the `io.EOF` error in that case.

http://play.golang.org/p/cbWe9se76d

Bam!

That post is a piece of garbage. He's clearly angling for a language like Rust or Haskell that has a very complex type system for preventing errors in the code, and no other language would succeed with the way he was writing code (which was completely inane). It's like he jumped in a plane, hit full throttle ahead and complained the plane crashed into the ocean instead of landing him safely in Seattle.

Getenv returns an empty string just like unset env variables act like an empty string on the command line. If it returned an error, people would complain it works differently than they're used to. You can't please everyone.

Reply on news.ycombinator.com