Perhaps. But if Go itself adds exceptions they're going to have to catch a MassDeveloperExodusException. The standard reason I see for people wanting exceptio

Perhaps. But if Go itself adds exceptions they're going to have to catch a MassDeveloperExodusException. The standard reason I see for people wanting exceptions in Go is because they're sick of writing the following: ```go thing, err := things.New() if err != nil { log.Fatalln(err.Error()) // Or `return err` } ``` But I would argue that it means they're not writing idiomatic go. A good reference for the value of error values is this go blogpost[0]. The HN discussion[1] of that post was also interesting, I like this comment in particular: > In Go I not infrequently make use of a non-nil value AND a non-nil error. A canonical example of this is the io.Reader interface in Go's standard library [1]. I think it is a very useful idiom particularly when dealing with things where failure is more normal - e.g. dealing with network services, disk IO, decoding partially corrupt exif data from images. Often you want a best-effort at the value even if you run into problems. Handling every error from every function that returns an error can be verbose. But for that verbosity you get a much easier to understand failure model, and the tools (defer) to handle failures reliably no matter what comes up. Exceptions are part of the reason that RAII is so critical in the C++ world. [0]: https://blog.golang.org/errors-are-values https://blog.golang.org/errors-are-values [1]: https://news.ycombinator.com/item?id=8877502 https://news.ycombinator.com/item?id=8877502