Proposal for an exception-like mechanism

Thanks for your answers.

Ian Lance Taylor <[email protected]> wrote:

Thanks, question answered, and it's probably the appropriate
choice.

Now, those could be useful: I can imagine a defer() function picking one
of those up and giving useful (and likely different) data to both the
user of the application (who probably can't fix it) and the programmer
(who usually wants to).

Users find stack traces very unappealing, however useful they are
to programmers!

(Ian -- are you trying to sell me on exceptions being useful after
all? Hmm ....)

Pretty much what I expected. Indeed, I suspect if this proposal is
adopted it'll be common to declare a suitable defer() function early in
a goroutine's existence, just to take over control of the error
reporting so a compiler warning probably wouldn't help much: if there's
no appropriate defer(), there probably wasn't meant to be one.

I'm familiar -- one might say overly familiar -- with the term from 8+
years of kernel support for a Unix vendor. If used in similar
circumstances and as little as possible, I don't really object. If
you've painted yourself into a corner and can't levitate, you're out of
options, after all.

I would like to think there are fewer cases for libraries to panic than
for kernels to panic, of course, but good library design is non-trivial.

(And certainly during development panic wouldn't hurt in a language
without assertions; making it blatantly obvious to developers and Q&A
departments that "yes, we know this doesn't work yet" isn't nutty when
they hit something that's not implemented yet. Woe to the developer and
reviewers who let one of those out into a product though!)

I concur. (I've fought similar arguments about library functions that
spat error messages out to what they *thought* was standard error.
Library functions shouldn't do that, either.)

I suspect nobody will come up with a clever enough suggestion, because
sometimes it may be the library that has something panic-worthy happens.
One example would be a "can't happen" case in a library triggered by
hardware data corruption: a panic would sometimes not be out of order
there, any more than it would be within a kernel.

(A "can't happen" based on corrupt input would be another matter:
that would just be an error, IMHO. Programs should expect and be
prepared for corrupt input.)

+1

In both languages I've found them a PITA, as I've had to code all this
extra "stuff" without much knowledge of what any of the individual
exception types was going to mean if I got one, at least until I buit up
an understanding of the underlying code. (Yeah, I have worked on too
many projects that have had totally inadequate documentation.)

> I don't think they have been succesful in those languages, ...

+1 also, but your knowledge of C++ and Java is well ahead of mine.

Thanks for the response. It answered of both my questions, and provided
more background to Rob's proposal (which I now suspect is not just Rob's
proposal :-).

Cheers,

Giles

Goexit would just be:

func Goexit() {
panic(runtime.Exiting)
}

if you have this then no-one can evade a defer
without taking down the whole program.

recoverable in the sense that you could abort some
number of function call frames and move on with
the rest of your program.

not recoverable in the sense that you could do something
to let the goroutine continue at the point of fault.

you shouldn't see many more invalid map accesses,
by the way. the next release will change the behavior
of m["no-such-key"] to return a zero value instead of
crash/panic. that change is already in tip.

russ

Thanks.

Also the exception proposal looks promising. :)

Very elegant.

It looks like testing for panics would incur very little overhead (as
compared to creating a try-catch frame).

Do you have a general idea of what runtime errors could be detected
and what would just crash no matter what? A few were discussed, div
by 0, array index out of bounds...

Regarding:

This would also be very cool. Right now I feel the syntax proposed is
a little bulky, but it is very precise. It seems tempting to creating
a generic "catch" syntax such as:
recover(x) {
printError()
}
rather then defer func() { x :=recover() }
but that may be taken as a C++, Java, C# style error handling. I
guess by writing out exactly what's happening there's much more
control, and these should be few and far between.

If this is able to handle handling and monitoring exceptions in other
goroutines, it sounds great! Otherwise, there may be a syntax that
can work with arbitrary goroutine exceptions... Hmm that thought
needs work.

> ...

I was and am uncomfortable about that too. But I'm still
thinking it through; in kernel land nested panics aren't
unusual (and nobody cares: only the first one counts, and
you're not trying to recover). And I don't think I _ever_ saw
more panics than one per CPU core and one extra, and I
wouldn't swear that I ever saw even that many in a single
crash.

On one hand, not allowing nested panics puts us right back
with "Your program exited. Sorry about that. Bye."

On the other hand, I agree the number of times that recovering
from a nested panic will then allow recovery from the initial
panic will be few, but disallowing this case seems harsh.

On the gripping hand, why stop at all? Can we have an
infinite cascade of panics? (Rob -- will we need a hard limit
at which point the runtime does throw up its hands in horror
and just bails out?)

Exceptions are tricky. After the discussion I've seen, I'm
becoming more enthusiastic about the proposal for Go, but
still fear that panic() will be way overused -- after all,
exceptions have been overused and abused in every language I'm
familiar with that has any form of them except perl, and
they're almost under the radar there, and there are plenty of
/other/ unwise things one can do in perl to mess with a
maintainer's sanity.

My take on this is still twofold, presuming the proposal or
a variant goes ahead (which I imagine it will):

a) the design and implementation has to be very, very careful
not to encourage overuse

b) as a community, much as preferred idioms (e.g. don't use an
'else' clause if you've called 'return' in the 'if' clause)
are already developing, we need to recognise and encourage
healthy (and only healthy) use of the new facility whatever
it turns out to be

Giles, possibly being pessimistic. Perhaps eggs sunny side up
will help. I think it's time to go and find out. :-)

What I like is to place my recovery at the beginning of the context,
without any more surrounding, indentation, and handling later. The
only thing I don't like is the notation. Defer is misused here, the
original idea is ok so. But I would like a statement like recover
taking a func with an empty interface. This func will be called if
there has been a panic().

func ImportantFunc() {
recover func(panic interface{}) { log.Stderrf("Ouch: %v", panic) }

DoSomething()

if IDontKnowWhatToDo() {
panic("I don't know what to do!")
}

DoMoreButOnlyWithNoPanic()
}

I hope I've been able to make my idea clear.

mue

i partially agree. i think that one flaw in the system as proposed
is, AFAICS, there's a performance penalty imposed in the non-exceptional
case - the code in the defer statement will be run regardless,
because the compiler doesn't distinguish between recovery
blocks and normal defer blocks.

perhaps i'm wrong here. can the compiler be clever enough
to make the following code avoid the closure allocation, function
call etc when b is non-zero?

func div(a, b int) (c int) {
defer func(){
if recover() != nil {
c = 0
}
}()
c = a / b
}

I don't like how recover() is a call to a closure which somehow magically closes the environment in which it is called. Every other fxn's environment is closed at the time it is defined, not when it is called!

Can we make recover a statement instead?

recover x
if x ...

That way it doesn't look like a fxn call with a magic environment. Instead it is a statement in the deferred fxn's environment.

Ryanne
- from my phone -

On Mar 25, 2010 1:37 AM, "Rob &apos;Commander&apos; Pike" <[email protected]> wrote:

This proposal differs from the usual model of exceptions as a control structure, but that is a deliberate decision.  We don't want to encourage the conflation of errors and exceptions that occur in languages such as Java.

Proposal
-----

First, we tweak the definition of defer.  At the moment, it's defined to run deferred functions after the result values are copied back to the caller's stack. We change the definition slightly to say they run after the return values are evaluated but before they are copied to the caller's stack.  This makes the output variables available to deferred closures.  Thus a deferred closure can modify the return values of the caller of the deferring function.

The function

       func numDefer() (n int) {
               for i := 0; i < 100; i++ {
                       defer func() {
                               n++
                       }()
               }
               return
       }

will return 100.   With the existing spec, it would return 0, if it weren't also illegal (the closure was not allowed to refer to n at all due to the prohibition on taking the address of return values; that has been lifted too).

[This much is now checked in to the spec.]

Next we define a pair of predefined functions:

       func panic(v interface{})
       func recover() (v interface{})

[This is a redefinition of panic, and we delete panicln altogether.]

The function panic begins a process called panicking.  Panicking unwinds the deferred calls, executing each in turn.  In other words, each function on the stack, including the one that calls panic, is terminated, in reverse order, with its deferred calls executing as they terminate.

During panicking, if a deferred function invocation calls recover, recover returns the value passed to panic and stops the panicking.  At any other time, or inside functions called by the deferred call, recover returns nil.  After stopping the panicking, a deferred call can panic with a new argument, or the same one, to continue panicking.  Alternately, the deferred call might edit the return values for its outer function, perhaps returning an error.

Here is a simple example.

       func f(dopanic bool) {

                               fmt.Printf("panicking with value %v\n", v)
                               panic(x)  / go back to panicking
                       }
                       fmt.Printf("function returns normally")
               }()
               fmt.Printf("before")
               p(dopanic)
               fmt.Printf("after")
       }

       func p(dopanic bool) {
               if dopanic {
                       panic(3)
               }
       }

If the function f is called with dopanic=true, it will print

       before
       panicking with value 3

and generate a stack dump showing that f called function p which called panic. Otherwise, it will print

       before
       after
       function returns normally

and return without crashing.

If we remove the call to panic in f, and call it with dopanic=true, it will print

       before
       panicking with value 3
       function returns normally

and not generate a stack trace.

Since a deferred function may modify named return parameters, a function may recover from a panic and signal that it has done so through its return value.  For instance, given

       func f(dopanic bool) (err os.Error) {

                               err = x.(os.Error)
                       }
               }()
               q(dopanic)
               return
       }

       func q(dopanic bool) {
               if dopanic {
                       panic(os.ErrorString("bad karma"))
               }

       }

If dopanic is true, f will return the error "bad karma"; otherwise it will return nil.

As mentioned above, the recover function can return non-nil only when it is executed directly by a deferred function while panicking.  This allows panics to stack and avoids a problem in cases such as the one illustrated here:

       func foo() {
               defer func() {
                       if bar() != nil {
                               os.Exit(0)
                       }
               }()
               panic(3)
       }

       func bar() (err os.Error) {

                               fmt.Printf("bar is panicking")
                               err = x.(os.Error)
                       }
               }()
               if horribleNewProblemHappens() {
                       panic("disaster")
               }
               return nil
       }

Here we see foo call panic, which then calls bar during the deferred function.  We do not want bar to act as if it has triggered a panic itself; it should only return an error if there has been a horrible new problem.  This is the reason that recover can return non-nil only when executed directly in a deferred closure while the stack is unwinding and not while functions are called in defer blocks.



Implementation of defer, panic, and recover in gc
-----

Defer
-----

This is gc's implementation of the original defer (before any of the recent spec changes):

Each goroutine has a deferred call frame stack on which deferred calls are pushed.
Each entry records:

       SP at time of defer, aka SP of func that did the defer
       PC of function to call
       raw frame holding function arguments

A function that contains a defer statement ends with a special epilogue.  Instead of
the normal

       ADDQ $framesize, SP
       RET

it ends with

       CALL rundefer(SB)
       ADDQ $framesize, SP
       RET

Rundefer processes each entry on the top of the deferred call frame stack
that matches the current SP, writing each to the runtime stack and then
running that function.

If a deferred call inspects the call stack, it looks like it was called directly from f.

Allowing function return values to be addressed or stored in closures
means copying them to the heap on function entry (just like addressed
parameters) and then copying them back to the caller before the RET.
The copy back to the caller must happen after the call to rundefer.
That is the only change to support the editing of return values.


Panic and recover
-----

The processing of a particular panic stops when a deferred call pops the
corresponding entry off the panic stack and does not replace it (by invoking panic).
When that happens, the original call stack is unwound to the SP associated with
the deferred call that stopped the panic, making it appear that the function that
executed the corresponding defer statement is returning.  (This might in turn
cause the execution of other deferred code, in a non-panicking context.)

The processing of a panic also stops when the deferred call stack has emptied.
If the latter happens, the program crashes, printing the value passed to panic
and then the full stack trace at the time the panic started.


Recursive panics
-----

If a child of a deferred call panics, or if a deferred call panics without first calling
recover, a new panic begins that applies to the current call stack, including the
deferred call that was handling the first panic.  Thus:

       func f() {
               defer func() {
                       panic("second")
                       print("not reached")
               }
               panic("first")
       }

panics twice: the "first" panic runs the deferred func, which causes the "second"
panic.  The second panic aborts execution of the code in which it appears,
like panic always does, so the print is not reached.  In this program, the second
panic will empty the deferred call stack, causing the program to crash.
When it does, it prints the stacked panic values, oldest first, and then the stack trace.


Stack traces
-----

runtime.Caller works inside deferred code just as it does inside normal code.
During normal execution, the caller of deferred code is the function that
executed the defer statement.  During a panic, the caller of deferred code
is panic itself.  During a recursive panic, earlier panics are visible on the
call stack.  For example, this program:

       package main

       import (
               "fmt"
               "runtime"
               "strings"
       )

       / Print names of functions on call stack.
       func stack(msg string) {
               fmt.Print(msg, ":")
               var stk [10]uintptr
               n := runtime.Callers(2, stk[0:])
               for _, pc := range stk[0:n] {
                       s := runtime.FuncForPC(pc).Name()
                       if i := strings.Index(s, "."); i >= 0 { / cut package name
                               s = s[i+1:]
                       }
                       fmt.Print(" ", s)
                       if s == "main" {
                               break
                       }
               }
               fmt.Println()
       }

       func main() {
               f()
       }

       func f() {
               stack("in f")
               defer g()
               panic("first")
       }

       func g() {
               stack("in g")
               defer h()
               panic("second")
       }

       func h() {
               stack("in h")
               panic("third")
       }

prints

       in f: f main
       in g: g panic f main
       in h: h panic g panic f main

and then the program crashes, printing

       panic: first
       panic: second
       panic: third

       main.h+0x3e /home/rsc/x.go:35
               main.h()
       runtime.panic+0x45 /home/rsc/g/go/src/pkg/runtime/runtime.c:25
               runtime.panic()
       main.g+0x36 /home/rsc/x.go:29
               main.g()
       runtime.panic+0x45 /home/rsc/g/go/src/pkg/runtime/runtime.c:25
               runtime.panic()
       main.f+0x36 /home/rsc/x.go:23
               main.f()
       main.main+0x1d /home/rsc/x.go:18
               main.main()
       mainstart+0xf /home/rsc/g/go/src/pkg/runtime/386/asm.s:83
               mainstart()

Note that the panics are printed oldest first, but the stack trace is, as always,
newest frame first.

Being able to print the stack trace after running the deferred calls does not
require expensive operations like copying the stack when a panic happens:
all the deferred calls run like ordinary function calls, leaving the original
state at the time of panic intact.  The unwinding of caller frames only happens
when a deferred call stops the panic, if at all.

Russ,

In the original proposal, how does recover() return a value which depends on the fxn in which it is called? I realize it isn't actually a closure, but the fxn() syntax makes it look exactly like all other fxn calls. The result of a fxn call only depends on the parameters and its environment, normally. Since there are no parameters, I'm parsing it as a closure with an environment somehow magically linked to the fxn in which it is called.

Does that make sense? Is there a big reason not to make it a statement?

> I don't like how recove...

Roger,

Exactly, but how does the "recover" fxn access the panic state of the fxn in which it was _called_ ?

> of a fxn call onl...

Steven,

Ah that makes sense. I guess I overlooked that panic state is global to a goroutine. Thanks.

> In the original pr...

Roger,

The current fxn is not part of the global environment. A fxn cannot tell who called it, and certainly can't access the environment of the caller.
Not in the traditional sense of closures anyway.

> It doesn't depend on the function it i...

Roger,

Right. Runtime.Caller is also a magic function, but at least I expect as much with the runtime package. I'd hate to see magic functions adopted elsewhere.

> The current fxn is ...

It's not an issue of the call stack. The rule is that recover only
returns non-nil if called directly from a deferred function, rather
than from a function called from a deferred function. In this case f2
is a deferred function, but the function that f2 passes to defer is a
function called from a deferred function (though it is of course a
deferred function itself). So in this case the recover called
indirectly from f2 should not see the panic started in f1, so f1
should return false.

Replacing f2 with f3 still causes recover to be called directly from a
deferred function, so here f1 will return true.

Ian

Given how many people are asking for ways to make calling recover()
easier to use and more 'convenient' maybe it should be made *harder*
to use to avoid the abuse that will likely ensue.

We should remember something rob mentioned: most programs should not
contain more than one or two calls to recover, and I think in many
cases perhaps none at all (should a program like grep(1) ever call
recover()? probably not).

My biggest fear is that people will build libraries that force client
code to use recover to deal with perfectly normal errors. Maybe to
discourage this panic() should be renamed
THEWORLDISGOINGTOENDWEAREDOOMED() ;)

uriel

I very much agree with your posting. It's hard for me to think of a
situation where I would want to issue a panic outside the runtime.
And then using recover would only be a means to recover despite
program errors in a module and rare hardware failure. If an "error"
can be defined and anticipated ahead of time, it should not be a panic
(it should be a normal error).

What if you are only allowed to issue a panic statement inside unsafe
code or inside the runtime?
You can still check for recover anywhere.

Any thoughts of limiting where panic can be issued?

-Daniel

Does this only apply to deferred functions?

Ellie

Eleanor McHugh
Games With Brains

instead of this, you could do something like this:

func recovery() {
switch x := recover().(type) {
case nil:

case Panic:

default:
panic(x)
}
}

i don't really see what advantage you gain from having an Exception type.