FWIW, this is exactly why I built trycatch (
https://npmjs.org/package/trycatch). trycatch works for all the use cases
listed here:

* Call once, and all proceeding async calls and uncaught exceptions are
properly handled
* Nesting works as expected (exactly how nesting synchronous try/catch
blocks would behave)
* Not reliant on 3rd party modules to implement in order to work
* Long stack traces
* Works properly with EventEmitter

Granted, trycatch ATM doesn't offer the resource cleanup, but in theory it
could be combined with domains to accomplish this just fine. I may do so
when I get the chance now that domains are little more stable, assuming
they wouldn't interfere. In the other thread you mentioned above (
https://groups.google.com/forum/?fromgroups#!topic/nodejs/RphMf98jcgA)
where I'm discussing a few of these things, I included the following
example where domain nesting fails, but succeeds just fine with trycatch:

https://gist.github.com/4075399

Nothing against domains. I just find them to be cumbersome and to not solve
the problems I face, esp. wrt. libraries not properly handling
Errors/exceptions.

Cheers,
Adam Crabtree


On Wed, Nov 14, 2012 at 2:58 PM, Forrest L Norvell <[email protected]>wrote:

> On Wednesday, November 14, 2012 at 2:28 PM, pie_lard wrote:
>
> On Wednesday, 14 November 2012 22:04:15 UTC, Forrest L Norvell wrote:
>
> On Wednesday, November 14, 2012 at 1:35 PM, pie_lard wrote:
>
> Suppose node were changed to remove the feature that lets domains track
> EventEmitters.  So domain.add(), .remove() and .members would all be
> removed.  The code that automatically adds new EventEmitters to the active
> domain (if there is one) would also be deleted.  Finally, suppose .bind()
> and .intercept() were also removed.
>
> As an aside, you should only have to call domain.{add,remove} on a handle
> or an emitter yourself under very specific (and rare) conditions.
>
> That would just leave domain.run() - plus the ability to create new
> domains and possibly nest them.
>
> Would that be enough to effectively recreate synchronous stack-based
> exception handling?
>
> No, and I'll explain why below.
>
> My answer would be yes - and in fact it would remove my connection-pool
> problem altogether without any need for the 3rd-party module authors to
> change anything.
>
> To put it another way; in what real-world circumstances would you need the
> features I just removed?
>
> Please understand I ask this as a bit of a node noob ;)  It's not a
> criticism of domains - I would like someone to explain why I'm wrong about
> this.
>
> The problem is it's impossible to know in advance whether a chunk of code
> is going to use EventEmitters or not, and without domain code there to wrap
> them, you'd lose the necessary state to tie a specific request to a
> specific domain. Consider the following (buggy / incomplete) Express
> handler:
>
> app.get('/test', function (req, res) {
>   var d = domain.create();
>   d.on('error', function (error) { res.send(500, 
> {"content-type":"text/plain"}, error.stack); });
>   d.run(function () {
>     fs.readFile(FILENAME, 'utf-8', function (err, contents) {
>       // process.domain should be available here
>       res.send(contents.replac**e(/:/gm, '/'));
>     });
>   });
> });
>
>
> The call to res.send is going to happen several passes through the event
> loop after the initial handler is called. It's entirely possible that in
> the time the file is read from disk, another several requests to that
> handler are going to have come in to the server. Without dealing with the
> EventEmitters, how will any errors emitted inside the fs.readFile callback
> be connected back to the enclosing domain?
>
> Maybe this is what I'm misunderstanding!  I was under the impression that
> your example would in fact work (ie. that your domain handler would catch
> an error thrown by the res.send() call).
>
> The docs say:
>
> Additionally, callbacks passed to lowlevel event loop requests (such as to
> fs.open, or other callback-taking methods) will automatically be bound to
> the active domain. If they throw, then the domain will catch the error.
>
> Doesn't that imply that you've done all you need to do in the above code?
>  That just by starting the chain of callbacks inside run() that the active
> domain will persist through them?  And that as you're creating a new domain
> per request the domains won't get confused - the correct res object will be
> available when an error is thrown?
>
> BTW: I didn't mean to imply that the domain code inside node could do this
> without wrapping EventEmitters or something similar.  Just that (a) it
> should do so behind-the-scenes and (b) the wrapping shouldn't take the form
> of binding the EventEmitter to whatever domain happens to be active when
> the emitter was created.
>
> I think we're very close to getting in sync here. Yes, with the domains
> code internally wrapping EventEmitters, the above is totally enough to trap
> errors on the correct domain. I was asking how that would work *without*
> EventEmitters being wrapped.
>
> You shouldn't have to deal with any of the EventEmitter stuff. It should
> all be handled for you as an app developer behind the scenes. domain.add /
> domain.bind / domain.intercept are mostly for the use of a small subset of
> Node developers who maintain modules that use long-lived EventEmitters
> shared among a number of clients. If / when those modules are patched to
> work with domains, your need as an end user to deal with any of this
> stuff should vanish. At that point, yes, you should just be able to call
> domain.run() within your handlers and everything should Just Work. Sorry if
> I haven't made that clearer!
>
> 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
>



-- 
Better a little with righteousness
       than much gain with injustice.
Proverbs 16:8

-- 
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

Reply via email to