[unscaled]

Would you suggest the same course of action for any language which uses exceptions? Because there is nothing special about the stack unwinding you get with panic/recover.

I'm seriously wondering if you ran into any trouble with recovering panics in production, because that would imply all Java, C#, Python, JS and Ruby server code in production which is happily catching and logging exceptions in the main request handler is constantly running into corrupted state.

[sleepydog]

That's not an accurate comparison. The issue is not the stack unwinding, but the root cause of the panic. In all of those other languages, exceptions are used for normal error handling in addition to "fatal" events. In Go, panics, if used at all, are generally used for fatal runtime errors (memory, segfault, etc), or in place of assert, and indicates a fatal, unrecoverable flaw in your program.

At every job I've worked at it was generally discouraged to handle MemoryError exceptions in python and OutOfMemoryError exceptions in Java. It's safer to assume there is nothing you can do on such occasions, because sometimes (usually the worst possible time) there isn't.

[lomnakkus]

Another relevant Java example might be VirtualMachineError (superclass of OutOfMemoryError) and the wonderfully named subclass UnknownError(!).