Here's another way of looking at what I proposed. When you call a function, you can divide what happens into 3 possibilities: 1) An exception is raised 2) You get back a generator 3) You get back something else (Yes, I'm ignoring aborts, sys.exit, etc). As it stands, all three of these are handled inside _inlineCallbacks (not in inlineCallbacks). With the code I suggested, the call to f is made before _inlineCallbacks is called. Only in case 2, where we actually have a generator, do we ask _inlineCallbacks to deal with unwinding it. In case 1 we pass the exception back via a deferred errback with a failure and in case 2 we pass the result back in a deferred whose callback is already called. There's a good case (perhaps a stronger one) for just letting the Exception go on its merry way and raise back in the calling code. But it's hard to argue that knowing that we don't even have a generator result that passing it on to _inlineCallbacks in the knowledge that it's going to cryptically raise is better than just returning the result of the user's function, especially seeing as it has just successfully run to completion! Terry