4 ms·

> The fact that this does not make it possible to keep exceptions from being fatal is a limitation on how strongly exceptions are handled. Maybe I'm missing so

• btilly 17y ago
  When an exception is thrown in a goroutine you climb the stack and any defer can trap the exception. However if you climb the stack of a goroutine to the top and there is no defer, you'll exit with a stack backtrace. So every goroutine has to have a defer if you want protection. The problem comes in the fact that goroutines are considered cheap and are launched for all sorts of reasons. Sometimes in large numbers. If even one of those goroutines does not have a defer set up, then an exception can crash the program. The use case I'm worried about is a webserver. In serving a web page I generally am happy to throw an exception, let it be caught at the top level, log it, then return a 500 page, internal server error. Watch your logs, fix the bugs, and release better software. However if you take this strategy with go, then the careless application programmer can accidentally take down the webserver. What I'd like to be able to do is have a smart person set the webserver up, and then be able to let more junior programmers write code for an application on top of it knowing that there are some limits to the likely damage that they'll do.
  • houseabsolute 17y ago
    > If even one of those goroutines does not have a defer set up, then an exception can crash the program. This might help. func GoCatch(f func ()) { go func () { defer func () { e := recover() if e != nil { log.Stderr(e.String()) } }() f() } }
    • btilly 17y ago
      Yes, but my concern was, and remains, what happens with third party libraries. The fact that I can rewrite my stuff easily does not mean that I can rewrite that stuff as easily.
      • houseabsolute 17y ago
        I guess I'm not really understanding the problem. What third-party library weakness do you think Go is especially susceptible to, exactly? An example would be nice.