Errors are values

What in Go is a return type of (Anything, error) with typically exactly one of the two being nil is in Rust the Result type, `enum Result<T, E> { Ok(T), Err(E) }`, something which is explicitly exclusively-either an OK T or an error E.

The equivalent of `x, err = expr; if err != nil { return err }` is very common in Rust; it would be written `x = match expr { Ok(x) => x, Err(e) => return Err(e) }`. It’s such a common pattern that a macro named try! was placed in the standard library for this incantation. Therefore you can write `x = try!(expr);` (or if you’re going to ignore the Ok variant, just `try!(expr)`).

Rust also warns you if you do nothing with a Result object; you can ignore the warning or suppress it, but it all makes it very much harder to ignore such error conditions. Go is one step up from C, where integral error-indicating return codes are the norm and are typically ignored, but I feel it’s still a fair way off the confidence that Rust gives me that I haven’t accidentally forgotten to deal with an error case. If you want people to get the message “Whatever you do, always check your errors!”, it helps if you design the language to make it hard for the user to forget.

(You people that know Rust, I’m ignoring the `FromError` part for simplicity. That’s only in libstd’s try!, anyway; libcore’s try! doesn’t have it.)

>We recently scanned all the open source projects we could find and discovered that this snippet occurs only once per page or two, less often than some would have you believe.

once per page? that's once per 30 or so lines. 2 or 3 percent of the code is this same repetitive structure? Also, only takes one time to forget this for everything to fall apart.

We've spent so much time trying to deal with uninit'd pointers and things like that on the language level, and here we have something that's much simpler, yet super repetitive and should be easy to catch on compile time.

Maybe I'm just a bad programmer, but I really prefer the Java "force you to catch exception" model much more to this.

>It's worth stressing that whatever the design, it's critical that the program check the errors however they are exposed.

If it's critical to check the errors, I think that it's worth writing language rules in a way to force people to write a "has error " code path (think pattern matching).

I get go is trying to be as small of a core as possible, but I think there's a lot of value in extra compiler checks (with no runtime cost!) to catch this sort of thing.

I get being against exceptions in a language like C++ where it can leave your program in a really weird state and have some ugly performance implications, but I don't get the argument in languages where it can work just fine.

The argument seems to be "you should be checking for errors anyway", but I feel like there are basically two types of errors: the obvious kind that you're going to check for anyway (or get bug reports), like network disconnects and bad files, and the "how the hell did that even happen" exception. For the obvious exceptions it seems like a wash, other than the try catch block being a bit cleaner, but for the "hell the hell did that happen" error exceptions seem way more useful. I'd much rather my program explode immediately than risk someone letting the error passing silently because people didn't check err because like "that will never happen". I know, functions can call panic and all that, but it just seems clumsy for no net gain.

I do think there's one type of error checking that doesn't get enough love (I don't know if Go has this, but I'm guessing probably?). "assert" that gets removed in release builds. It's kind of silly when you're working alone, but in a team of programmers or for libraries it's awesome, because it's basically like runtime documentation that gets compiled out. So you can warn your fellow devs about things without it bloating your program. The newer C++ has a really great feature called "static_assert", which is basically a compile time assertion, which can be handy for things like checking in various places that maybe if the count in enum changed, that you accounted for it in another spot of the code, or that certain aspects of a new platform sit right, or things like that.

Rather, (in Go) errors are values that violate type safety and destroy any correctness guarantees the compiler makes.

Languages like Rust and Haskell do this right. Both make heavy use of optionals for failable functions, and Haskell's support for HKTs (and therefore Monads) allows awesome stuff like Maybe or Either chaining.

Monads allow you to write code that, syntactically, looks like you're not doing any error handling. In reality, the error handling semantics are baked in at the Monad level. This makes sense, because error handling is usually very repetitive (e.g. "Check if the function we just called failed. If it did, return early. Otherwise, keep going." ad infinitum). As a (pseudcoded) example:

    parseTimeString :: String -> Either Error Time
    parseTimeString string = parse string $ do
            hours <- readHours
            semicolon
            minutes <- readMinutes
            semicolon
            seconds <- readSeconds
            return (Time hours minutes seconds)

If any of those steps fails, the entire computation will stop and the error message will be returned. This is roughly equivalent to checking for "nil" (in Go) after every function call, except you don't actually have to do it. This is defined in the code for the Either monad, which is at https://hackage.haskell.org/package/base-4.7.0.2/docs/src/Da... . As you can see, it's 4 lines of code.

(Side note: this is pretty much how you write parsers in Haskell using the Parsec library)

I disagree.

Of the various approaches I've seen to cope with this problem, Rust's try! macro is the most elegant.

Given the practical minded nature of Go and the core team's willingness to add in special cases to the language where appropriate, I think a Go version of try!() would be welcome and fit with the ethos of Go. It solves the 80% case and it doesn't mean the creation of a type-safe macro system.

The thesis of the blog post is that errors are values and thus you can program around the repetitive handling of them. But the proposed solution of writing a one-off implementation of Maybe like `errWriter` isn't an answer because:

1) Most importantly, when you need to call 3 functions which return differently typed values and can fail, there's nothing in the language to help you. This is the common case. 2) The implementation is now less obvious. To understand it, I need to read the `errWriter` helper code. 3) The code space you'll save by writing a new Maybe type is negligible.

This looks suspiciously like implementing Maybe every time you need to deal with a series of errors.

I'm a Go developer, but I don't buy this. At best it's showing how, with a bit of work (often times by the developer), errors aren't that bad. But I don't see how it's showing that it's better?

If you log the error when checking if ew.err != nil, which might be many lines or even a different function, you'll have a hard time getting a meaningful context (which is hard to do in Go in the best case), like a stack.

I think Peter Norvig's quote "Design patterns are bug reports against your programming language" is a perfect fit for this situation.

The stdlib's compress/bzip2 internally does the same sort of thing where you do a bunch of operations and then check for errors: http://golang.org/src/compress/bzip2/bit_reader.go#L12

And regexp uses panics to propagate parse errors up the stack internally, and that's even described in Effective Go: http://golang.org/doc/effective_go.html#recover

In both cases an error value is returned to the package user.

In general, I think you should feel freer do abnormal things that suit your situation within a package as opposed to across API boundaries. The standard ways of doing things should still be preferred when it's not too costly: the standards are what they are for a reason (even if the tradeoffs they represent are more appealing in some situations than others), it's easier to read code that's written in the way everyone's used to, and standards help keep you from spending time bikeshedding unimportant details. But the surface area of your package is the first thing users will have to learn, and what you have to keep in your head whenever maintaining code that uses your package--that's what it's most important to make clean and normal-looking and consistent.

I know the post talks about using an unusual error-handling pattern in an API, and you can do that sometimes, too. Just trying to make a separate point--when you're thinking about doing unusual stuff, keep in mind there's a big difference between an unusual implementation and an unusual API.

This article is bizarre. I've read it twice expecting an actual solution to null checking basically everywhere and it doesn't actually present one.

I'll stick with discriminated unions in F#, thanks. Errors are values, correct. But it seems hardly any languages actually bother to grok the concept. If your language doesn't provide type safety for ensuring that you capture all resulting conditions then it has failed its job.

That second-last example with errWriter destroys safety AFAICT, since it requires the user to remember to check for ew.err to see if the whole sequence of operations actually succeeded or not.

Atleast the last example with flush returning the error made sense, since that's an explicit "commit" operation that the user must call for correctness. However not every series of operations has a final commit operation, so this technique is unsafe in general.

(In fact even flush might be optional? I didn't check the docs.)

Edit: The docs for flush say nothing, but the docs for the Writer interface itself ( http://golang.org/pkg/bufio/#Writer ) do:

> After all data has been written, the client should call the Flush method to guarantee all data has been forwarded to the underlying io.Writer.

Go lacks a construct comparable to "with" in Python, or WITH-OPEN-FILE in Lisp, to guarantee that things get closed out on scope exit. Go has "defer", but that's a clunky replacement. You have to explicitly write the "defer", and it's always function-scope, not construct-scope.

Most of the problems with exceptions in C++ come from the C++ memory model - allocation and deallocation in exceptions are usually painful, and care must be taken to clean up and unlock things. Go doesn't have that problem - it's garbage collected.

Go does have "panic", which is Go's answer to "longjmp". People keep trying to use that as an exception mechanism, which is not a good thing.

Python seems to have the best track record with exceptions. Python's usual problem with exceptions comes from library functions which, under some rare circumstance, raise an unexpected exception and take down the whole program. This is mostly a legacy problem due to the poor original design of Python's exception hierarchy. You would like, for example, for everything that can possibly go wrong with an HTTP read or a network operation to be a subclass of EnvironmentError, as caused by an external event or data. That wasn't the case originally. There are still problems in Python 2.7 with getting a ValueError because some low-level data item was bad UTF8 or something like that.

The trouble with the "errors are values" concept is that error details tend to get lost as errors propagate upward. This came up yesterday on HN in connection with network errors for GoGo's airborne networking service. I once argued that D's error type should have a "why" pointer slot, so that, when you passed an error upward, you could link the lower-level error to the higher level error. The error message printer would then list out the errors, yielding something like

    Unable to complete transaction
    because database update failed 
    because database connection was lost
    because of network error "Host down".

"I was wrong about Gopher's Law. The probability of mentioning generics in a #golang discussion starts at 1 and raises with time." - Dave Cheney.

Article posted 1 hour ago. Ctrl-F Generics = 3 matches

If a function be advertised to return an error code in the event of difficulties, thou shalt check for that code, yea, even though the checks triple the size of thy code and produce aches in thy typing fingers, for if thou thinkest ``it cannot happen to me'', the gods shall surely punish thee for thy arrogance.

One thing I love about the repetitive err pattern is that I find my self wrapping/appending errors with useful context more frequently (rather than say catching an exception five frames further down and just appending "mylib: oops").

I realise the later was just laziness on my part, but the constant err checking really does force good habits on me, which of course yields higher quality code that's easier to reason about when something goes wrong.

Lua uses this to handle errors---I don't find it really tedious. A common pattern is kind of the same---to return either one return value and nil and then an error message or an error code (Lua, like Go, has multiple returns) in case of errors. This results in code like

    let res, err = some_function()
    if res == nil then -- you can also check for err ~= nil like in Go
       -- return from this function with something, err contains more
       -- information
    end

I think it's very neat---you can also return nil, err from this function if you can't deal with it and some code up the stack should be able to handle it in a meaningful manner. I don't find it particularly tedious; i.e. not less tedious than writing try..catch blocks, and you can clearly see where are the function exit points, whereas with exceptions, any line can theoretically throw an exception. A missed error check can be troublesome, but generally using nil as a value further down in the function will hopefully trigger another error which might be then caught so you can spot the bug.

Lisp's continuations are also IMHO a great mechanism---you catch the error and then you can tell the function down the stack what it should do: you can abort, or you can try fixing the error and continuing, or you can try again for some number of times and then report a new error if that fails. It's more flexible than stuff I've heard of before.

I don't know if I'm just ignorant, but I like that Go forces me to use real estate for dealing with errors. It's the first language I've used where I give as much attention and design to the "sad paths" as I do to the "happy path". And I'm very comfortable navigating through text files and folding blocks of code, so it doesn't bother me if handling an error costs me a few lines.

Macros like try! might take up less space, but is that really a bottleneck for your work?

How about just using beloved tables instead? Maybe even with function literal to prepare some stuff, if you need to.

   for _, s := []string {
      p0[a:b],
      p0[c:d],
      // ...
   } {
      _, err = fd.Write(s)
      if err != nil {
         return err
      }
   }

As others already implied it could have been cleaner with exceptions, but I don't think this is that one case where exceptions are particularly important. There is no recursion yet or anything like that.

I think explicitly handling error like go is a good thing. Error handling is a tricky thing that needs thought to get right and should be expressed clearly in the code. My only complaint is that `if e != nil { return e }` takes 3 lines of code. Could `gofmt` format that into one line with no line breaking, I am already pretty happy. If they could add a keyword like `ereturn` that only returns when the last parameter (must be error) is not nil, just as an alias, I would be totally satisfied.

Errors are absolutely values and that's a great perspective for any language to take. Essentially, you can see an errorful computation as "returning" either a valid return value as expected or an error. In Go the quotes are eliminated: that is exactly what happens

    ret, err = fd.Write(...)

Above we have two (initial) possibilities

    1. The return was error-free, err = nil, and 
       ret is an interesting return value.
    2. The return was errorful, err != nil, err 
       instead details the reason for error as 
       an integer, and ret is nonsense.

This is a little challenging because we must be sure to check err in the second case since otherwise ret is silently meaningless. This is a source of bugs called "Boolean Blindness".

In a language with Sum types we'd represent this by saying that errorful computations adjoin an error type to the return type.

    Int ----> Either Error Int 

What's nice is that this automatically ensures the above invariant of err/ret is held: a value of type Either Error Int is either "Right i" for some valid Int i or "Left e" for some error value e. The first thing we check is the handedness of the result and thus know the result of the computation.

Sum types like Either solve Boolean Blindness because we literally cannot get access to our return type Int unless it is valid: if we find that the result is "Left e" then all we have is an Error value.

(Ultimately what this boils down to is that product types like (ret, err) behave very differently from sum types and cannot replace them.)

If Go had generics we would also notice that the error-passing behavior of Either is naturally ignorant of the particular choice of types Error and ain't. We could manipulate it meaningfully (and indeed write the functionality used in this article) for any and all values e and r as the type Either e r. Then upon use Either e r would specialize to Either Error Int.

It's easy to argue that this is silly: we only need one error type and it is not difficult to replicate this code. I'll argue for now that only having one error type is at best confusing and at worst a lie. Different processes and functions have different exceptional states. Coercing all of this variation in error meaning into the same error type ensures that misunderstandings and accidental unifications will occur.

Honestly, I really love Go for making sure that errors were values: it is an incredible step forward for making exceptional cases more reasonable. Unfortunately, Go does not seem expressive enough to build the machinery which makes this style of error handling all of reasonable, non-repetitive, and non-confusing.

"Error are values", OK, but as a non-Go programmer, how do you handle idiomatically the most common case of wanting to bubble the error up the stack and turn it into something human-readable? Bonus if you do not break encapsulation. Double bonus if you get a stack trace out of it.

The handling of errors in go is weird if one only returns or breaks on errors. But it works fine if one does something on error, in almost every error check in my go code I have a log.Println with a human readable text like "could not read from the application configuration file." much nicer to get errors like that than a stack dump and a message like could not read from file $filename.

"There is one significant drawback to this approach, at least for some applications: there is no way to know how much of the processing completed before the error occurred. If that information is important, a more fine-grained approach is necessary."

A more fine-grained approach which is conveniently omitted from the article, BECAUSE IT'S SPAMMING `if err != nil` EVERY OTHER STATEMENT...

If you want to force the consumer to consider an error case and make some decision about it... Well, I actually like Java's checked exceptions.

You've got to emit an error somehow and static checking ensures the consumer won't accidentally ignore the case. (Deliberately, perhaps, but that's a people-problem rather than a technology one.)

I don't get it. How is "errors are values" different from anything? In what language are errors not values?

Being an erlang programmer I am so used to programming for the correct case and not to check errors but let the process crash when you get an error or, rarely, use a try that I find this style of programming completely wrong. It is what we are trying to avoid. You will always miss cases.

Saying it's so doesn't make it true. You can declare that an error is simply a special value returned and expect people to check for that value all over the place, or you can declare that errors are (literally) "exceptions" and should therefore throw.

Pike's solution does not help very much, and only exposes how little work the Go compiler is actually doing to ensure your code is safe and sensible.