zlacker

>>djha-s+(OP)
To me, much of this reads like the author wants to do something bad, the language doesn’t let him, and he views that as a pain point. For example, killing a thread at an arbitrary line is a terrible idea, and the fact that Go doesn’t have that feature is probably for the best.

Some other points show a lack of understanding. In Java, you also can’t catch exceptions from another thread. Go panics are mostly equivalent in this sense - you get a defer (finally) block, which is what supposedly matters to you for cleanup, and you must have a recover (catch) within your thread.

Overall I’m not a fan of how this is presented as some kind of deep thinking, when in fact it’s so many surface observations and misunderstandings about how things work.

>>t8sr+8e
In Java you can set an uncaught exception handler, so you can make sure exceptions are caught in child threads from the parent.

In Go, defer blocks are only run for the panicking goroutine. Other goroutines do not run defer, the program simply crashes.

>>djha-s+FC
Sure, if the program crashes, all bets are off. That’s also true of any other similar exception mechanism.

The fact that the program crashes on unhandled panic, rather than letting you install a default global handler, is a design choice that has nothing to do with how goroutines are implemented.