This higlights a point why I actually prefer exceptions to manually passing around error codes.

If any of these calls to panic() are inside libraries, by using that library, you will put yourself into a position where your application will exit without giving you any recourse to fix it.

I've seen too many C libraries doing this too - "mmh - I can't handle this right now - let me just call exit()" (last time this happened was inside a commerical library for reading excel files. If it was confronted with a file that was corrupt in some way, the library would call exit(), terminating my application server in the process. Thanks)

With exceptions, a library can just throw but I as a consumer of the library at least get a chance to handle the error somehow and who knows - I might be able to find some way to still proceed and not crash.

If I don't handle that exception, oh well, then I crash anyways, but that's not different from the library calling exit or panic.

With exceptions, I also never risk that I (or a library I use) forgets to check for an exit code and proceeds to corrupt data (or crash way later at a seemingly unrelated point).

When I fail to catch an exception, I my application dies.

When I fail to check an error code, my application might possibly corrupt data.

Just because implementing exceptions in compiled languages is difficult and messy (C++) and because exceptions are slow doesn't mean we shouldn't be using them. It means that we have to improve our language and OSes in order for them to work without hacks and quickly enough because, honestly, the value they provide to me is big enough to warrant a bit of research.

Panic is not exit. http://golang.org/pkg/os/#Exit is exit

Panic is throw. Recover is an isomorphism for catch.

For the most part. You have to explicitly ignore error codes in go. (Not that you can't handle them incorrectly.)

> You have to explicitly ignore error codes in go. (Not that you can't handle them incorrectly.)

I'm not sure I udnerstand what you mean. I can write:\nfmt.Fprint(os.Stdout, "Something\\n")

This returns an error, which I silently discard. Did you mean something else?

fmt.Fprint(os.Stdout, "Something\\n")

By itself isn't a valid statement. You try to compile that and you'll get an error saying unused return value. So you'll try:

err := fmt.Fprint(os.Stdout, "Something\\n")

and you could ignore err, but then you'll get a compiler saying err is defined but never used. So you can be like NAH I'm just trying to muck stuff up so I"m going to do this.

_ = fmt.Fprint(os.Stdout, "Something\\n")

Which is explicitly discarding the error much like:

try{\n fmt.Fprint(os.Stdout, "Something\\n")\n}catch(Throwable t){}

I'm sorry, but that's not true: http://play.golang.org/p/PiMXQkKOef

For simply dropping all return values on the ground, there are linters that will complain for you: https://github.com/kisielk/errcheck