

An (official) proposal for an exception-like mechanism in Google's Go - uriel
http://groups.google.com/group/golang-nuts/browse_thread/thread/1ce5cd050bb973e4#

======
btilly
From this one ill-behaved goroutine could take down your program.

I'd like to see a mechanism where you could launch a goroutine such that it,
and any goroutines it launches, all have a top level defer. That lets you
launch potentially questionable third-party libraries in a goroutine safe in
the knowledge that they will not take down your whole program.

Otherwise I like it.

~~~
houseabsolute
> From this one ill-behaved goroutine could take down your program.

That's already possible so no change there. The child routine need only call
panic or crash and it will destroy your program.

~~~
btilly
Right. There is currently no exception handling and so exceptions are fatal.
The point of exception handling is to make it possible to make exceptions not
be fatal.

The fact that this does not make it possible to keep exceptions from being
fatal is a limitation on how strongly exceptions are handled.

~~~
uriel
> 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 something, but this does allow you to keep exceptions from
being fatal using defer.

~~~
btilly
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
> 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
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
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.

