Well it does demonstrate that, and I think that is a good attribute of Go. (And ...

jamwt · on Feb 11, 2014

Not if you want to parameterize the exceptions. This kind of "matching" requires that you compare your exception "types" by exception "values", so you cannot provide parameterized information about what exactly failed.... which key? Which URL?

Underpowered error handling (and I'm not advocating for exceptions, persay), lack of generics (and the resultant copypasta party and interface{} runtime casting [aka, the return of void *]) are real warts in an otherwise fine language.

And I'm not just theorizing: I spend my days writing a large, nontrivial system in go.

I've used Haskell a lot before, and I'm not asking for no nulls or real ADTs (though I wouldn't complain), but generics + better typed errors would really help clean things up.

Meanwhile, a lot of us are just waiting for rust...

beatgammit · on Feb 11, 2014

Maybe I'm missing something, but you can do this with a type switch: http://play.golang.org/p/jF_bPQdwxk

It just depends on what you're trying to accomplish, but most use-cases can be accomplished without exceptions. The other use-cases often indicate bad design.

As for generics, you can get 90% of the way there with interfaces. The use of `interface{}`--while sometimes necessary--is often an indicator of bad design.

In large code bases, you often don't need (or care) to know what underlying type something is. For example, you shouldn't care whether an `io.Reader` is a TCP socket, file or completely in-memory ala `io.Pipe()`.

There are times when type assertions are the best/only way to get something done, and that's why they're there, but those cases should be relatively infrequent.

Generics would make some things easier (Rust's implementation is quite nice), but it's not significantly impacting my productivity, and I certainly wouldn't consider switching languages just because Go lacks them.

EDIT: Added info about generics

azernik · on Feb 12, 2014

Errors in Go are custom types; your error can be defined as, for example:

    type URLError {
        url String
    }

    func (e URLError) Error() String {
        return fmt.Sprintf("Invalid URL: %s", e.url)
    }

At which point a caller that wants to handle this error can either extract the URL to do fun things with it or just dump the Error() string.

4ad · on Feb 12, 2014

Of course you can, error is an interface, any number of concrete types can satisfy it, and you can use type assertions or type switches to unbox (and use) that concrete type.

This is a widely used idiom in Go.