bigeasy/connect — comment on commit 3bbd509b10106fa7b6d46c8ace4ebd7271ebe233
File:  line 0
By bigeasy:

I'm using Connect with Sreamline (and CoffeeScript) and the pass-through components work perfectly.

I loop over an array of handlers, making Streamlined calls to each handler, outside of the Connect HTTP container. The first to indicate that the response was handled, by returning true, terminates the loop. I handle errors by catching an exception thrown by the streamlined code, and then sending an error page styled for the site.

Streamline expects the Node.js convention of a callback with the signature `function (error, result) {}`. The pass-through functions, like csrf, bodyParser, and logger for example, operate as streamline expects. They raise an error on error, but do not return anything.

I don't expect that Connect should fit my use case perfectly. The return value of true is not important. There are other ways track that.

The Connect notion of propagating errors through callbacks does happen to fit Streamline perfectly. Since this handler does forward the file system exception though the call chain, the intent of this patch was to go for consistency and forward all errors through the call chain.

From this exchange, I can see that the error propagation was intended for exceptionally exceptional conditions. HTTP errors are considered a normal part of an HTTP request that should not be propagated through the chain to the catch all handler. I obviously start from a notion that 400 errors are just as much a part of the unhappy path as 500 errors.

It might be the case that I'm making Connect do something that it should not do. It is certainly not my intent to campaign to alter Connect in a way that would break Express. I do like the Streamline loop and the linear expression of handling and try catch for errors, however. It seemed to just fall out of putting Connect and Streamline together.