Handling exceptions in callback API

[squaremo]

Many operations in the promise and the callback APIs can give rise to errors, either because

1. the server didn't like what you asked for and signalled an error
2. the client code broke
3. the application code (i.e., the callback) threw an exception

In general, 1. is handled by emitting an error from the channel; 2. is a bug, so bets are off.

With 3., the promises library will redirect an exception thrown in a success continuation to the (eventual) error continuation. However, this sort of behaviour isn't possible for the callback API, which essentially invokes callbacks in the top-level context.

The simplest solution is probably to wrap the outermost frame handlers in try-catch blocks, and redirect any exceptions as 'error' events.

[squaremo]

Commit c007e43 adds error handling to the callback RPC machinery. Specifically, it redirects errors thrown in callbacks to channel 'error' events (thereby closing the channel).

Arguably this diverges from the semantics of the promise API: there, an error thrown in a success continuation won't break the channel, though it will of course result in an error continuation being called. There's no obvious other way to surface errors in the callback API, but I wonder if it's appropriate for the promise API to do the analogous thing and close the channel, or even whether it's possible -- maybe not, thinking about it.

[squaremo]

Actually, I don't think redirecting errors is the right thing to do. If an error is thrown in callback code, it should crash. 'error' should be reserved for operational errors, that is, the socket closing and what have you.

[gjohnson]

I agree, node-amqp does the former and it's difficult to tell whether an error is due to network conditions or you app level code sucking. Wrote some thoughts on this a few months back: https://gist.github.com/gjohnson/7566343

[squaremo]

I reverted this in ae5a495