a panic() can be recovered by invoking recover() in the preceding frames.
but i have observed that a throw() cannot be recovered using same way.
i saw runtime package uses a throw() function in many places in runtime, but this throw i am not able to recover using recover. It crashes by sending a signal to itself and invoking exit(2).
did i miss something/ is there a way to handle/revover runtime.throw() ?
PS: the use of throw i am referring to is in file “/usr/local/go/src/runtime/plugin.go:25”
There is no throw() in the language. The thing you’re referring to is an unexported function in the runtime it uses to abort with a “fatal error” message when it can no longer continue for some reason.
Well, then the difference is that one (“panic”) is a language feature and the other is a function to print an error and shut down. Or I’m not really sure what you’re asking, maybe.
when a runtime.throw() is invoked inside the runtime, all we see is stack traces being written on terminal and program exits, same as in case of an unhandled panic.
perhaps the programmer was not expecting this and thinks this can be handled by adding a recover(), so that the application can continue.
but is surprised that this is not the case. (i.e. adding a recover() does not make the program to continue execution)
When the runtime has run into enough trouble that it needs to (do the equivalent of) panic, there is nothing the rest of the program can do to recover the situation. Hence the “fatal error” phrasing. It really is fatal.
I myself am new to Go, but it sounds to me as if the confusion is simply due to this function being named “throw”. I looked in src/runtime/panic.go and it appears that throw() is indeed designed to never return (it calls startpanic() and dopanic(), which has comments that say “should never return”.
Perhaps it might be less confusing to people used to traditional OO languages if it were named “exit_fatal” or something but there’s no need to be constrained by other languages’ traditions.
… and as @calmh said throw() is unexported, so devs should not normally even see this routine.
but there’s no need to be constrained by other languages’ traditions.