On Wednesday, November 14, 2012 at 4:02 PM, Adam Crabtree wrote: > You missed the point of the example about domain nesting failing. > > `err.errors` is a mongoose thing, not a trycatch thing. It was my attempt at > a plausible uncaught exception in the strained example. The original gist was > correct: > https://gist.github.com/4075562/4c0e389da3e15048c2c99629eca28b8d96a7ebad > > Nonetheless, the point stands that domain nesting doesn't work and the > process dies if you have an async error in a callback coming from a library > that uses domains, and had any sort of internal failure, a use-case in which > trycatch handles seemlessly. I see what you mean, and I see what the issue is. Not popping the domain where an error originates on a throw seems like a bug, not a purposeful omission or design decision.
Trycatch handles the core case of errors really well, but domains are a more general abstraction, and have a whole bunch of other applications. I use something very similar to domains (I need less than they offer, and I need to support versions of Node < 0.8) because I spent a while using hook.js from trycatch, and wasn't able to get it to handle a lot of the cases I needed (which were more about propagating state across an async call chain than capturing exceptions and errors. The potential I see in domains is that they're a very simple mechanism that nicely maps to the unique set of design choices embodied in Node (i.e. asynchronous with no standard promises, single threading, high concurrency). > Or to put it another way, it's not possible with domains (AFAIK) for > `domainFoo` to return an Error to its callback if the 3rd-party library uses > domains to return async errors, and as I mentioned in the other thread, this > is my primary use-case for async error-handling. Yes. Anything that doesn't handle this case is an incomplete solution. > Also, FWIW, I'm highly critical of domains for all the reasons stated above, > but I also very much want a solution to the problem they solve. My > recommended solution (with code) is trycatch, and as you can see from this > thread, I'm not the only one that would prefer a much cleaner, simpler > solution to error handling in node.js. > > That being said, I think node.js' error handling problem boils down to an > inability to catch asynchronous exceptions reliably, something that's > exacerbated by the lack of maturity of most 3rd-party libraries and node.js' > threadlessness and concurrency. uncaughtException is insufficient as it loses > context, and domains (at least currently) are insufficent for the reasons > stated above. I'm not sure all of those criteria can be addressed simultaneously without creating new problems. Trycatch isn't a lot of code, but there's a fair amount of complexity there, and shimming every call to process.nextTick, setTimeout, EventEmitters, et al is not without cost. F -- 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
