Have you tried this one? I wrote it, but I don't think I ever got around to integrating it into npm-www, so it might have some weird edges still. Bugs and patches welcome!
https://npmjs.org/package/domain-http-server On Wed, Jun 19, 2013 at 9:36 AM, Martin Cooper <[email protected]> wrote: > > > > On Tue, Jun 18, 2013 at 1:57 AM, Ryan Schmidt <[email protected]> > wrote: >> >> Thanks. Emitting errors is working somewhat. >> >> >> I've read about domains but haven't worked with them before. I tried using >> them a couple days ago and found that using domains with connect (and >> therefore express) is not straightforward. I found a module to help with >> this: >> >> https://npmjs.org/package/connect-domain >> >> But it behaved strangely: The first time I hit an error page it showed up >> fine but subsequent error pages would cause the server to hang indefinitely. >> So I removed connect-domain. > > > One problem with this one is that it doesn't add the request and response to > the domain that it creates. In fact, it doesn't add anything; it seems to > assume you'll do that yourself, which rather defeats the purpose. Instead, > it seems to focus on disposing of the domain explicitly (which I believe is > not generally necessary). > >> >> Today I found another module for this: >> >> https://npmjs.org/package/express-domain-middleware >> >> I've included it and so far it hasn't done anything weird, though I'm not >> sure I fully understand how I need to modify my code throughout my project >> to make it catch all errors. > > > This is better, but if you encounter a problem before your code "goes > async", it won't be handled by the domain error handler, since that isn't > added to the domain until *after* domain.run() (and hence next()) returns. > The calls to run() and on() need to be switched. > >> >> Domains are probably a good thing for me to be using anyway, but I'm not >> sure if they help with the specific problems I'm having. > > > Domains are primarily for handling uncaught errors and exceptions. Since it > looks like you have error handlers in most places, it's not clear that an > error from spawn() will reach the domain error handler, if it ends up being > caught and handled elsewhere. > > -- > Martin Cooper > > >> Here's a simplified example of what I'm working on. This is a small >> express app that uses request to download an image from a server, pipes it >> through ImageMagick's convert program to resize it, and pipes that to the >> http response. >> >> https://gist.github.com/ryandesign/5803661 >> >> If the request succeeds, and ImageMagick works, then the resized image is >> displayed in the browser. Good. >> >> If there are any errors fetching the image using request, the http >> response is given that information with a suitable http error code. Good. >> >> But if there is an ImageMagick error, the error only ends up in the server >> log, and the browser receives an empty http code 200 response. For example, >> in server.js, change "-resize" to "-reesize" in the arguments when creating >> the ProcessStream. This causes ImageMagick to exit with an error code and >> display a message that "-reesize" is not a valid option. But I need to be >> able to send that error (or a sanitized version of it) to the browser. >> >> >> On Jun 18, 2013, at 00:19, Forrest L Norvell wrote: >> >> > Yes, emit errors instead of throwing them. If there's no error listener >> > attached, EventEmitter is special-cased to throw when errors are >> > encountered. That plus a domain used by the developer consuming the stream >> > (with the stream optionally added to the domain, if it's only going to be >> > used with a single domain) will make sure that the error gets routed to >> > where it needs to go. >> >> >> >> -- >> -- >> Job Board: http://jobs.nodejs.org/ >> Posting guidelines: >> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines >> You received this message because you are subscribed to the Google >> Groups "nodejs" group. >> To post to this group, send email to [email protected] >> To unsubscribe from this group, send email to >> [email protected] >> For more options, visit this group at >> http://groups.google.com/group/nodejs?hl=en?hl=en >> >> --- >> You received this message because you are subscribed to the Google Groups >> "nodejs" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> > > -- > -- > Job Board: http://jobs.nodejs.org/ > Posting guidelines: > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > You received this message because you are subscribed to the Google > Groups "nodejs" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/nodejs?hl=en?hl=en > > --- > You received this message because you are subscribed to the Google Groups > "nodejs" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > > -- -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
