Interesting, now all you need to do is add exceptions :)
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.
I don’t think that’s quite true. You definitely want RAII with exceptions, yes, but RAII is extremely useful even without exceptions. I believe it’s common to disable C++ exceptions but still use RAII.
If you have multiple returns from a function (which can very easily happen with manual error checking) RAII is a big win.
Which is another way of saying exceptions are part of the reason for RAII.
You’re free to write exception-full code using those constructs, although the community tends to use error return values for the most part.
https://stackoverflow.com/questions/44504354/should-i-use-pa...
> You should assume that a panic will be immediately fatal, for
> the entire program, or at the very least for the current
> goroutine. Ask yourself "when this happens, should
> the application immediately crash?" If yes, use a panic;
> otherwise, use an error.
See an example in the standard library itself: https://golang.org/src/encoding/json/encode.go, line 295
What's frowned upon is leaking this out of your package's interface/contract.
Java/Python encourage the use of exceptions as returning error conditions, rather than return error codes.