Hacker News Reader

You know what happens when your library spins a goroutine and that goroutine crashes? Your program crases, and you don't have the chance of putting any recovery on it.

Your library with buggy goroutines take down the whole program, and there is nothing you can do to fix it.

View on HN

Isn't that the same if you make a completely synchronous library without any goroutine? If your library panics then the whole program crashes.

It's not the same because for any single goroutine, you can catch the panic at top level. But it only works if you wrote the top-level code for each goroutine. (For a completely synchronous program, you wrote the main function.)

If all the work is done with one function call, it might be pretty similar to a program crash, except that you can log or restart in main, and you could use it as part of a larger program that does other stuff too.

From what I understand, Go code is usually written with the assumption that panics are fatal, not recoverable as exceptions. Trying to recover from them, as though they were exceptions, will expose other bugs, like functions not using defer to do cleanup, releasing mutex and such.

Reply on news.ycombinator.com