> When the code running inside (the inner) domain d1 throws and d1's error
> handler calls the callback from (the outer) domain d2 with the error, the
> error in d2's callback gets emitted on d1's error handler because d1 wasn't
> cleanly exited. Either domain.bind() needs to run its callback inside a try
> / catch / finally block that emits the error on the domain handler and then
> exits the domain, or the uncaughtException handler installed by the domain
> module needs to figure out how to clean up the domain's state. The former
> seems a lot simpler, and would fix this problem for domain.run, domain.bind
> and domain.intercept, which is probably good enough for now and keeps
> everything relatively simple (although it incurs the overhead of v8 not
> being able to optimize try-catch blocks).
I don't want to speak on Adam's behalf, but I think his point was that with trycatch the error ends up in the right place, whether or not the error is the fault of the devs or a third party module. That seems like a good base-level requirement for domains as well.
I'll see if I can put together a pull request to address this.
F
On Nov 14, 2012, at 19:17, Jake Verbaten <rayn...@gmail.com> wrote:
> So it fails because `console.log(err.errors[0])` throws a `err` does not have `errors[0]` property.
> Is this not a bug in thirdParty because it calls the callback before it disposes the domain?
> cc izs: this should probably be fixed or documented at least.
> On Wed, Nov 14, 2012 at 6:37 PM, Forrest L Norvell <forr...@newrelic.com> wrote:
>> On Wednesday, November 14, 2012 at 6:24 PM, Jake Verbaten wrote:
>>>> https://gist.github.com/4075562/4c0e389da3e15048c2c99629eca28b8d96a7ebad >>> Why does it fail?
>> When the code running inside (the inner) domain d1 throws and d1's error handler calls the callback from (the outer) domain d2 with the error, the error in d2's callback gets emitted on d1's error handler because d1 wasn't cleanly exited. Either domain.bind() needs to run its callback inside a try / catch / finally block that emits the error on the domain handler and then exits the domain, or the uncaughtException handler installed by the domain module needs to figure out how to clean up the domain's state. The former seems a lot simpler, and would fix this problem for domain.run, domain.bind and domain.intercept, which is probably good enough for now and keeps everything relatively simple (although it incurs the overhead of v8 not being able to optimize try-catch blocks).
Forrest is exactly right. I would add to it, it's not just about it ending
up in the right place, but about it getting caught at all, though in this
context they're pretty much the same thing.
Ya, sorry, it really wasn't necessarily the best example, but often
presenting reasons for why an API is failing, in order to convince someone
that it is actually a bug, you must first convince them it's a legitimate
use case. The result is a pretty strained example (though in real code, it
comes up regularly), but I was just trying to provide an example of when
someone might generate a new error in a callback after the originating
function returned an error.
On Wed, Nov 14, 2012 at 7:32 PM, Forrest L Norvell <forr...@newrelic.com>wrote:
> I don't want to speak on Adam's behalf, but I think his point was that
> with trycatch the error ends up in the right place, whether or not the
> error is the fault of the devs or a third party module. That seems like a
> good base-level requirement for domains as well.
> I'll see if I can put together a pull request to address this.
> F
> On Nov 14, 2012, at 19:17, Jake Verbaten <rayn...@gmail.com> wrote:
> So it fails because `console.log(err.errors[0])` throws a `err` does not
> have `errors[0]` property.
> Is this not a bug in thirdParty because it calls the callback before it
> disposes the domain?
> cc izs: this should probably be fixed or documented at least.
> On Wed, Nov 14, 2012 at 6:37 PM, Forrest L Norvell <forr...@newrelic.com>wrote:
>> On Wednesday, November 14, 2012 at 6:24 PM, Jake Verbaten wrote:
>> When the code running inside (the inner) domain d1 throws and d1's error
>> handler calls the callback from (the outer) domain d2 with the error, the
>> error in d2's callback gets emitted on d1's error handler because d1 wasn't
>> cleanly exited. Either domain.bind() needs to run its callback inside a try
>> / catch / finally block that emits the error on the domain handler and then
>> exits the domain, or the uncaughtException handler installed by the domain
>> module needs to figure out how to clean up the domain's state. The former
>> seems a lot simpler, and would fix this problem for domain.run, domain.bind
>> and domain.intercept, which is probably good enough for now and keeps
>> everything relatively simple (although it incurs the overhead of v8 not
>> being able to optimize try-catch blocks).
