2013-09-23: Defer, Panic, and Recover in Racket

In this post, we show how to implement defer, panic, and recover from the Go language in about fifty lines of Racket macros. If you aren’t familiar with these Go features, I’ll be trying to adapt the Go documentation into the post, so don’t worry.

-

These features attempt to provide something like exception handlers and Racket’s dynamic-wind. Defer delays an expression’s evaluation until after the rest of the function returns (successfully or not). Panic is like throwing an exception and Recover is a procedural interface to inspecting if an exception is currently being thrown. Recover in normal code is like a no-op, but inside of a Deferred expression it is like a handler. One difference, however, is that Recover always recovers regardless of the kind of exception thrown and you must explicitly re-throw if the "handler" can’t handle that kind of error.

Here’s a small example of just Defer.

This function returns 1 and prints out 0. In Go, Defer statements must always be a single function call and not an arbitrary expression. This is because Go will evaluate the arguments to the function before saving the call, which is why this function prints out 0 and not 1. The macros I show implement a slightly more general version that accepts any sequence of expressions. What my macro allows is done in Go by writing an inline thunk... that is manually writing out the expansion of this macro:

For an analogy to traditional Racket, this use of Defer is equivalent to:

As you can see, this style of programming is quite painful. We can easily imagine a defer macro that cooperated with define to transform the program into this output. It would be easy if defer had to occur at the function’s top-level, but would be much more complicated if defer could occur anywhere. In the future, I’ll investigate that option, but for now we’ll make a simpler version that is more dynamic. The output will be like:

It is important, however, that there can be many deferred functions and that they are executed in Last In First Out order. For instance, this function should print "3210" and not "0123".

This is very convenient to implement with a cons list and a queuing/queue-consuming function like:

We’ll use a syntax parameter called queue-defer to communicate the particular add-deferred function to the defer-funcall macro.

The only interesting thing about this macro is that it is forces a function application syntax and evaluates the arguments before constructing the closure that will be called later.

One thing that Go supports that we will not is the ability for deferred functions to modify the named return values after they have been computed by the main body. This would be complicated to add because Racket doesn’t have named return values, but I think the effort would be orthogonal. Once you had them, you would get modification in deferred code for free by composing the macros.

The more interesting behavior comes from Panic and Recover. The Go documentation contains the following example:

This program has a call sequence of main, then f, then three calls to g, before potentially having a Panic. The Panic causes the rest of the final call to g to not execute and instead the deferred expressions in previous g calls run before the deferred Recover in f takes control. If recover? is #t, then the output is:

But if recover? is #f, then the final two lines are not printed and the Panic ultimately kills the thread as a traditional uncaught exception would.

In our Racket implementation, we will represent Panic as throwing a particular kind of exception and encode Recover has inspecting the "current" Panic.

In this code, we implement Go’s behavior of a Recover leaving an impact on the Panic through the use of a mutable field on the exn:panic structure.

This code cooperates with the define/dpr macro, which installs the following exception handler around all the code that it executes:

After a Panic is observed, we still run the deferred code and afterwards, if one of them did not Recover, then we raise the Panic again, so the next layer can fail.

We can wrap these pieces together with a simple macro:

The only interesting thing here are that we use begin0 to return the result of the body even though we run the deferred code afterwards.

At this point, all the tests on the Go documentation page pass correctly. I wrote a little macro that allows us to easily run something while checking its return value and what its output is.

At this point, we have a conforming implementation of Defer, Panic, and Recover. Unfortunately, this implementation has some strange behavior that the Go language documentation does not comment on what should happen. It all has to do with what should happen when Panics occur inside of Deferred code. For instance, consider this:

I would expect this to return 3210, but with the above implementation it returns 3232. Unfortunately, Go does not provide us with the behavior it should be. Since it feels right to me, let’s change it to be 3210.

The problem is that the two calls to run-defers—in the success and the fail case—do not coordinate with each other to ensure that a deferred computation only happens a single time. We can fix that with a new interface to the defer queue. We’ll replace <deferred-interface> with

The key here is that as run-defers is executing, it removes the deferred values from the list by replacing them with #f. It is important it removes them before they return, because otherwise the failing deferred expression would be run twice.

However, this implementation still doesn’t survive another weird example, where there are multiple Panics during the Defer stage. For instance,

It returns 32!1 and not 32!10.

The problem is that inside of <panic-handler> when it calls run-defers, the Panic handler is not re-installed to deal with further Panic events inside the same call frame. We can solve this by moving the handler inside of run-defers:

This allows us to refactor define/dpr a little because the first call to run-defers does not need to be inside of two with-handlers forms:

Now, we’ve successfully implemented a plausible version of Defer, Panic, and Recover. Unfortunately we don’t know if it is what the Go designers intended, since they are vague in their specification.

As a final shot, something that is unfortunate about this implementation is that it is not safe-for-space. The begin0 accumulates space on the stack to check to see if any Defers had taken place. You might think that you could check at the time of the call in tail position if any had been accumulated, but the Racket implementation is more powerful than the Go version, because you can write code like:

In this example, the defer in the higher-order argument refers to the Defer of the not-safe function and not the anonymous function. In Go, you are restricted to only first-order uses of Defer, so this is apparently not a relevant concern.

The Racket version also has some unintuitive behavior like the following where a higher-order result causes Defers to an earlier call:

This particular Defer is not observable, because the Defer goes into the past. But using continuations, we can "go back in time" and see it:

This program outputs

This is actually unsurprising, because as we discussed in the beginning, defer is a special case of dynamic-wind, which is specifically designed to deal with continuation-based time travel.

1 Yo! It’s almost time to go!

But first let’s remember what we learned today!

Go’s Defer, Panic, and Recover are special cases of dynamic-wind and exception handling, but with a convenient syntax that does not induce right-ward drift.

Racket’s macro system allows us to recreate Go’s behavior and syntax.

Go does not specify what the behavior of Defer, Panic, and Recover is in great enough detail to determine what they should do when there are "recursive" Panics. It would not be sufficient to look at Go’s implementation, because that would only tell us what it happens to do, not what it should do.

Defer necessarily consumes stack space and our implementation is not pay-as-you-go and cannot be made to be due to its power over Go’s version, specifically because it allows higher-order, non-top-level uses of Defer.

If you’d like to run this exact code at home, you should put it in this order: