trycatch catches all uncaughtExceptions with long stack traces and can be
nested. We use trycatch in production at RedRobot (http://redrobot.com/),
adding a great deal of stability and proper error handling (500s). We also
use it in conjunction with our control-flow library stepdown which
incorporates it at every "step" if it's installed.
The following example catches and properly passes back all errors generated
both by it, passed to its callbacks, or uncaughtExceptions in core or 3rd
party module code complete with long stack traces, allowing you to fail
gracefully, ignore the error, or let it bubble.
var $$ = require('stepdown')
function foo(arg, callback) {
$$([
function($) {
asyncOne(arg, $.first())
asyncTwo(arg, $.first())
}
, function($, res) {
var onNestedComplete = $.first()
// Nesting
$$([
function($) {
setTimeout(function() {
// Async error
// Will bubble to nestedCallback
throw new Error('will be caught')
})
}
, function ($) {
// not called
}
]
, function nestedCallback(err) {
// ignore above error
err = err && err.message === 'will be caught' ? null : err
onNestedComplete(err)
})
}
// Pass unhandled exceptions and callback errors
], callback)
> More than a couple people mentioned try/catch not working in node.js in > the Fibers 0.5 thread (
> https://groups.google.com/forum/?fromgroups#!topic/nodejs/5hv6uIBpDl8), > so I thought I'd offer a friendly reminder of the trycatch module that > handles these situations nicely.
> FWIW, try/catch doesn't have to be broken in node.js and it doesn't have > to lost state any more than you're willing to let it:
> trycatch catches all uncaughtExceptions with long stack traces and can be > nested. We use trycatch in production at RedRobot (http://redrobot.com/), > adding a great deal of stability and proper error handling (500s). We also > use it in conjunction with our control-flow library stepdown which > incorporates it at every "step" if it's installed.
> The following example catches and properly passes back all errors > generated both by it, passed to its callbacks, or uncaughtExceptions in > core or 3rd party module code complete with long stack traces, allowing you > to fail gracefully, ignore the error, or let it bubble.
> More than a couple people mentioned try/catch not working in node.js in
> the Fibers 0.5 thread (
> https://groups.google.com/forum/?fromgroups#!topic/nodejs/5hv6uIBpDl8),
> so I thought I'd offer a friendly reminder of the trycatch module that
> handles these situations nicely.
> FWIW, try/catch doesn't have to be broken in node.js and it doesn't have
> to lost state any more than you're willing to let it:
> trycatch catches all uncaughtExceptions with long stack traces and can be
> nested. We use trycatch in production at RedRobot (http://redrobot.com/),
> adding a great deal of stability and proper error handling (500s). We also
> use it in conjunction with our control-flow library stepdown which
> incorporates it at every "step" if it's installed.
> The following example catches and properly passes back all errors
> generated both by it, passed to its callbacks, or uncaughtExceptions in
> core or 3rd party module code complete with long stack traces, allowing you
> to fail gracefully, ignore the error, or let it bubble.
That looks nice, but the shortcoming of such solutions is the burden of
error handling falls on the library authors. Unfortunately, in my
experience, 3rd party module code failing is the most common source of
uncaughtExceptions. This makes perfect sense, since robustness comes after
feature-completeness. If I need a dropbox module, and am first
to implement one against their new REST API, I'll make sure it works for
100% of my use cases, but not necessarily 100% of all use-cases (I'm a busy
man). Nonetheless, I would still open-source and fix any bugs that occur
(maybe).
This is a common theme in node: unreliable 3rd-party libraries, and the
general advice is, make sure you trust their code like it was your own, but
that's a little silly considering we've just met; they seem trustworthy and
I need what they're selling... They may even be completely trustworthy, but
they have a masochistic penchant for throwing Errors in asynchronous
callbacks when a null response would be appropriate (think async version of
JSON.parse). I need to know when these failures occur so I can handle
and log them appropriately. Intentionally letting the server crash and
restarting is an absurd proposition.
@Tim
ATM, domains are easy to break. Here's a quick example of domains failing
when nested, whereas trycatch handles the error as expected. Ideally, I'll
eventually roll the domain resource management into trycatch, but for now,
they don't work for most of my use cases.
Actually, Schoon tore all the old code out. ;P It's only still step in the
spirit of it being consecutive steps, for which you very much get credit.
=) You should take a look, it's dramatically different.
Here's a quick list of added features:
* Optional centralized async error handling
* Short circuit to next step
* Short circuit to callback on error or uncaught exception
* Short circuit to callback
* Errors on timeout for steps whose callbacks don't get called <- A huge
cause of unexpected "no server response" bugs
* Generators for in-step callbacks (steps complete if non are generated,
regardless of return value) <- Allows for the base condition of returning
something (synchronously) in a step and not worrying about it being
undefined and the step not progressing
* Explicit first variable, all arguments, event-style (no error) callback
support
* No failure to progress if group generator not called
* $.data shared between steps
* Binding to event emitter events for callbacks
* Composability
* Dependency-injection style substeps via $.run (create a new set of steps
from within a step)
On Wed, Nov 14, 2012 at 11:12 AM, Tim Caswell <t...@creationix.com> wrote:
> Adam, I'm glad you're still using that code! Out of curiosity, have you
> compared it to domains?
> On Wed, Nov 14, 2012 at 11:57 AM, Adam Crabtree <atcrabt...@gmail.com>wrote:
>> More than a couple people mentioned try/catch not working in node.js in
>> the Fibers 0.5 thread (
>> https://groups.google.com/forum/?fromgroups#!topic/nodejs/5hv6uIBpDl8),
>> so I thought I'd offer a friendly reminder of the trycatch module that
>> handles these situations nicely.
>> FWIW, try/catch doesn't have to be broken in node.js and it doesn't have
>> to lost state any more than you're willing to let it:
>> trycatch catches all uncaughtExceptions with long stack traces and can be
>> nested. We use trycatch in production at RedRobot (http://redrobot.com/),
>> adding a great deal of stability and proper error handling (500s). We also
>> use it in conjunction with our control-flow library stepdown which
>> incorporates it at every "step" if it's installed.
>> The following example catches and properly passes back all errors
>> generated both by it, passed to its callbacks, or uncaughtExceptions in
>> core or 3rd party module code complete with long stack traces, allowing you
>> to fail gracefully, ignore the error, or let it bubble.
Now I've seem got the point.
Your lib substitutes functions of main async modules' (fs, setTimeout, eventemitter, etc) - this helps to cover 3rd party modules as well.
And your lib knows how to print long stack traces.
Except this all the work seems similar to what the control-block does.
Is that correct?
Also regarding performance: I see you create "new Error". Not sure I understand if it's really needed prelimiary (even if no error is thrown), but consider that this drops performance of a simple scenario:
for (var i = 0; i < 1000000; i++) {
trycatch(function() {}, function() {});
}
from 10M iteration/sec with _TOKEN_.error = null; down to 150K/sec with _TOKEN_.error = new Error.
четверг, 15 ноября 2012 г., 6:04:54 UTC+7 пользователь Adam Crabtree написал:
> That looks nice, but the shortcoming of such solutions is the burden of > error handling falls on the library authors. Unfortunately, in my > experience, 3rd party module code failing is the most common source of > uncaughtExceptions. This makes perfect sense, since robustness comes after > feature-completeness. If I need a dropbox module, and am first > to implement one against their new REST API, I'll make sure it works for > 100% of my use cases, but not necessarily 100% of all use-cases (I'm a busy > man). Nonetheless, I would still open-source and fix any bugs that occur > (maybe).
> This is a common theme in node: unreliable 3rd-party libraries, and the > general advice is, make sure you trust their code like it was your own, but > that's a little silly considering we've just met; they seem trustworthy and > I need what they're selling... They may even be completely trustworthy, but > they have a masochistic penchant for throwing Errors in asynchronous > callbacks when a null response would be appropriate (think async version of > JSON.parse). I need to know when these failures occur so I can handle > and log them appropriately. Intentionally letting the server crash and > restarting is an absurd proposition.
> @Tim
> ATM, domains are easy to break. Here's a quick example of domains failing > when nested, whereas trycatch handles the error as expected. Ideally, I'll > eventually roll the domain resource management into trycatch, but for now, > they don't work for most of my use cases.
> Actually, Schoon tore all the old code out. ;P It's only still step in the > spirit of it being consecutive steps, for which you very much get credit. > =) You should take a look, it's dramatically different.
> Here's a quick list of added features:
> * Optional centralized async error handling
> * Short circuit to next step
> * Short circuit to callback on error or uncaught exception
> * Short circuit to callback
> * Errors on timeout for steps whose callbacks don't get called <- A huge > cause of unexpected "no server response" bugs
> * Generators for in-step callbacks (steps complete if non are generated, > regardless of return value) <- Allows for the base condition of returning > something (synchronously) in a step and not worrying about it being > undefined and the step not progressing
> * Explicit first variable, all arguments, event-style (no error) callback > support
> * No failure to progress if group generator not called
> * $.data shared between steps
> * Binding to event emitter events for callbacks
> * Composability
> * Dependency-injection style substeps via $.run (create a new set of steps > from within a step)
> Cheers,
> Adam Crabtree
> On Wed, Nov 14, 2012 at 11:12 AM, Tim Caswell <t...@creationix.com<javascript:>
> > wrote:
>> Adam, I'm glad you're still using that code! Out of curiosity, have you >> compared it to domains?
>> On Wed, Nov 14, 2012 at 11:57 AM, Adam Crabtree <atcra...@gmail.com<javascript:>
>> > wrote:
>>> More than a couple people mentioned try/catch not working in node.js in >>> the Fibers 0.5 thread (
>>> https://groups.google.com/forum/?fromgroups#!topic/nodejs/5hv6uIBpDl8), >>> so I thought I'd offer a friendly reminder of the trycatch module that >>> handles these situations nicely.
>>> FWIW, try/catch doesn't have to be broken in node.js and it doesn't have >>> to lost state any more than you're willing to let it:
>>> trycatch catches all uncaughtExceptions with long stack traces and can >>> be nested. We use trycatch in production at RedRobot (
>>> http://redrobot.com/), adding a great deal of stability and proper >>> error handling (500s). We also use it in conjunction with our control-flow >>> library stepdown which incorporates it at every "step" if it's installed.
>>> The following example catches and properly passes back all errors >>> generated both by it, passed to its callbacks, or uncaughtExceptions in >>> core or 3rd party module code complete with long stack traces, allowing you >>> to fail gracefully, ignore the error, or let it bubble.
They're very similar in the problem they're solving . trycatch does what
guard does, but automatically, which is important, b/c it doesn't require
3rd party modules to implement it in order to catch their errors. Quick
example:
function proceed() {
// proceed
}
trycatch(function() {
blackBoxFn(proceed)
}, proceed)
In the above example, trycatch will catch any uncaughtExceptions
from blackBoxFn specific to this originating call, without blackBoxFn
needing to implement any error handling. In other words, trycatch gives you
contextual error handling and doesn't require 3rd-party support.
Regarding the performance, that's expected. Without the Error, you have no
means to trace your way back to the originating catch function and it would
effectively be the same as an uncaughtException handler without long stack
traces. The reason the Error is generated relates to the long stack traces
hack. In short, when Errors are constructed, their internal originating
stack trace is locked, and there's no way to reproduce this otherwise at a
later time. So it's a hack, but it's also the only way to accomplish long
stack traces without an approach similar to domains which requires
low-level pervasive bindings in core and an uncaughtException handler.
Honestly domains are something node.js desperately needs, and when the time
comes, and they are a little more mature and can accomplish the same thing
trycatch can, then trycatch will piggy-back on domains.
Cheers,
Adam Crabtree
On Wed, Nov 14, 2012 at 8:44 PM, Alexey Kupershtokh <
alexey.kupersht...@gmail.com> wrote:
> Now I've seem got the point.
> Your lib substitutes functions of main async modules' (fs, setTimeout,
> eventemitter, etc) - this helps to cover 3rd party modules as well.
> And your lib knows how to print long stack traces.
> Except this all the work seems similar to what the control-block does.
> Is that correct?
> Also regarding performance: I see you create "new Error". Not sure I
> understand if it's really needed prelimiary (even if no error is thrown),
> but consider that this drops performance of a simple scenario:
> for (var i = 0; i < 1000000; i++) {
> trycatch(function() {}, function() {});
> }
> from 10M iteration/sec with _TOKEN_.error = null; down to 150K/sec with _TOKEN_.error
> = new Error.
> четверг, 15 ноября 2012 г., 6:04:54 UTC+7 пользователь Adam Crabtree
> написал:
>> @Alexey
>> That looks nice, but the shortcoming of such solutions is the burden of
>> error handling falls on the library authors. Unfortunately, in my
>> experience, 3rd party module code failing is the most common source of
>> uncaughtExceptions. This makes perfect sense, since robustness comes after
>> feature-completeness. If I need a dropbox module, and am first
>> to implement one against their new REST API, I'll make sure it works for
>> 100% of my use cases, but not necessarily 100% of all use-cases (I'm a busy
>> man). Nonetheless, I would still open-source and fix any bugs that occur
>> (maybe).
>> This is a common theme in node: unreliable 3rd-party libraries, and the
>> general advice is, make sure you trust their code like it was your own, but
>> that's a little silly considering we've just met; they seem trustworthy and
>> I need what they're selling... They may even be completely trustworthy, but
>> they have a masochistic penchant for throwing Errors in asynchronous
>> callbacks when a null response would be appropriate (think async version of
>> JSON.parse). I need to know when these failures occur so I can handle
>> and log them appropriately. Intentionally letting the server crash and
>> restarting is an absurd proposition.
>> @Tim
>> ATM, domains are easy to break. Here's a quick example of domains failing
>> when nested, whereas trycatch handles the error as expected. Ideally, I'll
>> eventually roll the domain resource management into trycatch, but for now,
>> they don't work for most of my use cases.
>> Actually, Schoon tore all the old code out. ;P It's only still step in
>> the spirit of it being consecutive steps, for which you very much get
>> credit. =) You should take a look, it's dramatically different.
>> Here's a quick list of added features:
>> * Optional centralized async error handling
>> * Short circuit to next step
>> * Short circuit to callback on error or uncaught exception
>> * Short circuit to callback
>> * Errors on timeout for steps whose callbacks don't get called <- A huge
>> cause of unexpected "no server response" bugs
>> * Generators for in-step callbacks (steps complete if non are generated,
>> regardless of return value) <- Allows for the base condition of returning
>> something (synchronously) in a step and not worrying about it being
>> undefined and the step not progressing
>> * Explicit first variable, all arguments, event-style (no error) callback
>> support
>> * No failure to progress if group generator not called
>> * $.data shared between steps
>> * Binding to event emitter events for callbacks
>> * Composability
>> * Dependency-injection style substeps via $.run (create a new set of
>> steps from within a step)
>> Cheers,
>> Adam Crabtree
>> On Wed, Nov 14, 2012 at 11:12 AM, Tim Caswell <t...@creationix.com>wrote:
>>> Adam, I'm glad you're still using that code! Out of curiosity, have you
>>> compared it to domains?
>>> On Wed, Nov 14, 2012 at 11:57 AM, Adam Crabtree <atcra...@gmail.com>wrote:
>>>> trycatch catches all uncaughtExceptions with long stack traces and can
>>>> be nested. We use trycatch in production at RedRobot (
>>>> http://redrobot.com/), adding a great deal of stability and proper
>>>> error handling (500s). We also use it in conjunction with our control-flow
>>>> library stepdown which incorporates it at every "step" if it's installed.
>>>> The following example catches and properly passes back all errors
>>>> generated both by it, passed to its callbacks, or uncaughtExceptions in
>>>> core or 3rd party module code complete with long stack traces, allowing you
>>>> to fail gracefully, ignore the error, or let it bubble.
>> --
>> 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 nodejs@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+unsubscribe@googlegroups.com
> For more options, visit this
Any plans on making the long traces optional like trycatch(cb, cb2, true) or probably configurable using trycatch.enableLT()/disableLT() or process.ENV?
I would usually prefer more performance with short traces, and long ones only in development/testing environments. What do you think?
пятница, 16 ноября 2012 г., 2:57:56 UTC+7 пользователь Adam Crabtree написал:
> They're very similar in the problem they're solving . trycatch does what > guard does, but automatically, which is important, b/c it doesn't require > 3rd party modules to implement it in order to catch their errors. Quick > example:
> In the above example, trycatch will catch any uncaughtExceptions > from blackBoxFn specific to this originating call, without blackBoxFn > needing to implement any error handling. In other words, trycatch gives you > contextual error handling and doesn't require 3rd-party support.
> Regarding the performance, that's expected. Without the Error, you have no > means to trace your way back to the originating catch function and it would > effectively be the same as an uncaughtException handler without long stack > traces. The reason the Error is generated relates to the long stack traces > hack. In short, when Errors are constructed, their internal originating > stack trace is locked, and there's no way to reproduce this otherwise at a > later time. So it's a hack, but it's also the only way to accomplish long > stack traces without an approach similar to domains which requires > low-level pervasive bindings in core and an uncaughtException handler.
> Honestly domains are something node.js desperately needs, and when the > time comes, and they are a little more mature and can accomplish the same > thing trycatch can, then trycatch will piggy-back on domains.
> Cheers,
> Adam Crabtree
> On Wed, Nov 14, 2012 at 8:44 PM, Alexey Kupershtokh <
> alexey.ku...@gmail.com <javascript:>> wrote:
>> Now I've seem got the point.
>> Your lib substitutes functions of main async modules' (fs, setTimeout, >> eventemitter, etc) - this helps to cover 3rd party modules as well.
>> And your lib knows how to print long stack traces.
>> Except this all the work seems similar to what the control-block does.
>> Is that correct?
>> Also regarding performance: I see you create "new Error". Not sure I >> understand if it's really needed prelimiary (even if no error is thrown), >> but consider that this drops performance of a simple scenario:
>> for (var i = 0; i < 1000000; i++) {
>> trycatch(function() {}, function() {});
>> }
>> from 10M iteration/sec with _TOKEN_.error = null; down to 150K/sec with _TOKEN_.error >> = new Error.
>> четверг, 15 ноября 2012 г., 6:04:54 UTC+7 пользователь Adam Crabtree >> написал:
>>> @Alexey
>>> That looks nice, but the shortcoming of such solutions is the burden of >>> error handling falls on the library authors. Unfortunately, in my >>> experience, 3rd party module code failing is the most common source of >>> uncaughtExceptions. This makes perfect sense, since robustness comes after >>> feature-completeness. If I need a dropbox module, and am first >>> to implement one against their new REST API, I'll make sure it works for >>> 100% of my use cases, but not necessarily 100% of all use-cases (I'm a busy >>> man). Nonetheless, I would still open-source and fix any bugs that occur >>> (maybe).
>>> This is a common theme in node: unreliable 3rd-party libraries, and the >>> general advice is, make sure you trust their code like it was your own, but >>> that's a little silly considering we've just met; they seem trustworthy and >>> I need what they're selling... They may even be completely trustworthy, but >>> they have a masochistic penchant for throwing Errors in asynchronous >>> callbacks when a null response would be appropriate (think async version of >>> JSON.parse). I need to know when these failures occur so I can handle >>> and log them appropriately. Intentionally letting the server crash and >>> restarting is an absurd proposition.
>>> @Tim
>>> ATM, domains are easy to break. Here's a quick example of domains >>> failing when nested, whereas trycatch handles the error as expected. >>> Ideally, I'll eventually roll the domain resource management into trycatch, >>> but for now, they don't work for most of my use cases.
>>> Actually, Schoon tore all the old code out. ;P It's only still step in >>> the spirit of it being consecutive steps, for which you very much get >>> credit. =) You should take a look, it's dramatically different.
>>> Here's a quick list of added features:
>>> * Optional centralized async error handling
>>> * Short circuit to next step
>>> * Short circuit to callback on error or uncaught exception
>>> * Short circuit to callback
>>> * Errors on timeout for steps whose callbacks don't get called <- A huge >>> cause of unexpected "no server response" bugs
>>> * Generators for in-step callbacks (steps complete if non are generated, >>> regardless of return value) <- Allows for the base condition of returning >>> something (synchronously) in a step and not worrying about it being >>> undefined and the step not progressing
>>> * Explicit first variable, all arguments, event-style (no error) >>> callback support
>>> * No failure to progress if group generator not called
>>> * $.data shared between steps
>>> * Binding to event emitter events for callbacks
>>> * Composability
>>> * Dependency-injection style substeps via $.run (create a new set of >>> steps from within a step)
>>> Cheers,
>>> Adam Crabtree
>>> On Wed, Nov 14, 2012 at 11:12 AM, Tim Caswell <t...@creationix.com>wrote:
>>>> Adam, I'm glad you're still using that code! Out of curiosity, have >>>> you compared it to domains?
>>>> On Wed, Nov 14, 2012 at 11:57 AM, Adam Crabtree <atcra...@gmail.com>wrote:
>>>>> trycatch catches all uncaughtExceptions with long stack traces and can >>>>> be nested. We use trycatch in production at RedRobot (
>>>>> http://redrobot.com/), adding a great deal of stability and proper >>>>> error handling (500s). We also use it in conjunction with our control-flow >>>>> library stepdown which incorporates it at every "step" if it's installed.
>>>>> The following example catches and properly passes back all errors >>>>> generated both by it, passed to its callbacks, or uncaughtExceptions in >>>>> core or 3rd party module code complete with long stack traces, allowing you >>>>> to fail gracefully, ignore the error, or let it bubble.
alexey.kupersht...@gmail.com> wrote:
> Any plans on making the long traces optional like trycatch(cb, cb2, true)
> or probably configurable using trycatch.enableLT()/disableLT() or
> process.ENV?
> I would usually prefer more performance with short traces, and long ones
> only in development/testing environments. What do you think?
> пятница, 16 ноября 2012 г., 2:57:56 UTC+7 пользователь Adam Crabtree
> написал:
>> They're very similar in the problem they're solving . trycatch does what
>> guard does, but automatically, which is important, b/c it doesn't require
>> 3rd party modules to implement it in order to catch their errors. Quick
>> example:
>> In the above example, trycatch will catch any uncaughtExceptions
>> from blackBoxFn specific to this originating call, without blackBoxFn
>> needing to implement any error handling. In other words, trycatch gives you
>> contextual error handling and doesn't require 3rd-party support.
>> Regarding the performance, that's expected. Without the Error, you have
>> no means to trace your way back to the originating catch function and it
>> would effectively be the same as an uncaughtException handler without long
>> stack traces. The reason the Error is generated relates to the long stack
>> traces hack. In short, when Errors are constructed, their internal
>> originating stack trace is locked, and there's no way to reproduce this
>> otherwise at a later time. So it's a hack, but it's also the only way to
>> accomplish long stack traces without an approach similar to domains which
>> requires low-level pervasive bindings in core and an uncaughtException
>> handler.
>> Honestly domains are something node.js desperately needs, and when the
>> time comes, and they are a little more mature and can accomplish the same
>> thing trycatch can, then trycatch will piggy-back on domains.
>> Cheers,
>> Adam Crabtree
>> On Wed, Nov 14, 2012 at 8:44 PM, Alexey Kupershtokh <
>> alexey.ku...@gmail.com> wrote:
>>> Now I've seem got the point.
>>> Your lib substitutes functions of main async modules' (fs, setTimeout,
>>> eventemitter, etc) - this helps to cover 3rd party modules as well.
>>> And your lib knows how to print long stack traces.
>>> Except this all the work seems similar to what the control-block does.
>>> Is that correct?
>>> Also regarding performance: I see you create "new Error". Not sure I
>>> understand if it's really needed prelimiary (even if no error is thrown),
>>> but consider that this drops performance of a simple scenario:
>>> for (var i = 0; i < 1000000; i++) {
>>> trycatch(function() {}, function() {});
>>> }
>>> from 10M iteration/sec with _TOKEN_.error = null; down to 150K/sec with _TOKEN_.error
>>> = new Error.
>>> четверг, 15 ноября 2012 г., 6:04:54 UTC+7 пользователь Adam Crabtree
>>> написал:
>>>> @Alexey
>>>> That looks nice, but the shortcoming of such solutions is the burden of
>>>> error handling falls on the library authors. Unfortunately, in my
>>>> experience, 3rd party module code failing is the most common source of
>>>> uncaughtExceptions. This makes perfect sense, since robustness comes after
>>>> feature-completeness. If I need a dropbox module, and am first
>>>> to implement one against their new REST API, I'll make sure it works for
>>>> 100% of my use cases, but not necessarily 100% of all use-cases (I'm a busy
>>>> man). Nonetheless, I would still open-source and fix any bugs that occur
>>>> (maybe).
>>>> This is a common theme in node: unreliable 3rd-party libraries, and the
>>>> general advice is, make sure you trust their code like it was your own, but
>>>> that's a little silly considering we've just met; they seem trustworthy and
>>>> I need what they're selling... They may even be completely trustworthy, but
>>>> they have a masochistic penchant for throwing Errors in asynchronous
>>>> callbacks when a null response would be appropriate (think async version of
>>>> JSON.parse). I need to know when these failures occur so I can handle
>>>> and log them appropriately. Intentionally letting the server crash and
>>>> restarting is an absurd proposition.
>>>> @Tim
>>>> ATM, domains are easy to break. Here's a quick example of domains
>>>> failing when nested, whereas trycatch handles the error as expected.
>>>> Ideally, I'll eventually roll the domain resource management into trycatch,
>>>> but for now, they don't work for most of my use cases.
>>>> Actually, Schoon tore all the old code out. ;P It's only still step in
>>>> the spirit of it being consecutive steps, for which you very much get
>>>> credit. =) You should take a look, it's dramatically different.
>>>> Here's a quick list of added features:
>>>> * Optional centralized async error handling
>>>> * Short circuit to next step
>>>> * Short circuit to callback on error or uncaught exception
>>>> * Short circuit to callback
>>>> * Errors on timeout for steps whose callbacks don't get called <- A
>>>> huge cause of unexpected "no server response" bugs
>>>> * Generators for in-step callbacks (steps complete if non are
>>>> generated, regardless of return value) <- Allows for the base condition of
>>>> returning something (synchronously) in a step and not worrying about it
>>>> being undefined and the step not progressing
>>>> * Explicit first variable, all arguments, event-style (no error)
>>>> callback support
>>>> * No failure to progress if group generator not called
>>>> * $.data shared between steps
>>>> * Binding to event emitter events for callbacks
>>>> * Composability
>>>> * Dependency-injection style substeps via $.run (create a new set of
>>>> steps from within a step)
>>>> Cheers,
>>>> Adam Crabtree
>>>> On Wed, Nov 14, 2012 at 11:12 AM, Tim Caswell <t...@creationix.com>wrote:
>>>>> Adam, I'm glad you're still using that code! Out of curiosity, have
>>>>> you compared it to domains?
>>>>> On Wed, Nov 14, 2012 at 11:57 AM, Adam Crabtree <atcra...@gmail.com>wrote:
>>>>>> trycatch catches all uncaughtExceptions with long stack traces and
>>>>>> can be nested. We use trycatch in production at RedRobot (
>>>>>> http://redrobot.com/), adding a great deal of stability and proper
>>>>>> error handling (500s). We also use it in conjunction with our control-flow
>>>>>> library stepdown which incorporates it at every "step" if it's installed.
>>>>>> The following example catches and properly passes back all errors
>>>>>> generated both by it, passed to its callbacks, or uncaughtExceptions in
>>>>>> core or 3rd party module code complete with long stack traces, allowing you
>>>>>> to fail gracefully, ignore the error, or let it bubble.
> Yup. When I get the chance. Optionally also omit core and node_modules > lines in the long stack traces.
> On Fri, Nov 16, 2012 at 12:40 AM, Alexey Kupershtokh <
> alexey.ku...@gmail.com <javascript:>> wrote:
>> Any plans on making the long traces optional like trycatch(cb, cb2, true) >> or probably configurable using trycatch.enableLT()/disableLT() or >> process.ENV?
>> I would usually prefer more performance with short traces, and long ones >> only in development/testing environments. What do you think?
>> пятница, 16 ноября 2012 г., 2:57:56 UTC+7 пользователь Adam Crabtree >> написал:
>>> They're very similar in the problem they're solving . trycatch does what >>> guard does, but automatically, which is important, b/c it doesn't require >>> 3rd party modules to implement it in order to catch their errors. Quick >>> example:
>>> In the above example, trycatch will catch any uncaughtExceptions >>> from blackBoxFn specific to this originating call, without blackBoxFn >>> needing to implement any error handling. In other words, trycatch gives you >>> contextual error handling and doesn't require 3rd-party support.
>>> Regarding the performance, that's expected. Without the Error, you have >>> no means to trace your way back to the originating catch function and it >>> would effectively be the same as an uncaughtException handler without long >>> stack traces. The reason the Error is generated relates to the long stack >>> traces hack. In short, when Errors are constructed, their internal >>> originating stack trace is locked, and there's no way to reproduce this >>> otherwise at a later time. So it's a hack, but it's also the only way to >>> accomplish long stack traces without an approach similar to domains which >>> requires low-level pervasive bindings in core and an uncaughtException >>> handler.
>>> Honestly domains are something node.js desperately needs, and when the >>> time comes, and they are a little more mature and can accomplish the same >>> thing trycatch can, then trycatch will piggy-back on domains.
>>> Cheers,
>>> Adam Crabtree
>>> On Wed, Nov 14, 2012 at 8:44 PM, Alexey Kupershtokh <
>>> alexey.ku...@gmail.com> wrote:
>>>> Now I've seem got the point.
>>>> Your lib substitutes functions of main async modules' (fs, setTimeout, >>>> eventemitter, etc) - this helps to cover 3rd party modules as well.
>>>> And your lib knows how to print long stack traces.
>>>> Except this all the work seems similar to what the control-block does.
>>>> Is that correct?
>>>> Also regarding performance: I see you create "new Error". Not sure I >>>> understand if it's really needed prelimiary (even if no error is thrown), >>>> but consider that this drops performance of a simple scenario:
>>>> for (var i = 0; i < 1000000; i++) {
>>>> trycatch(function() {}, function() {});
>>>> }
>>>> from 10M iteration/sec with _TOKEN_.error = null; down to 150K/sec >>>> with _TOKEN_.error = new Error.
>>>> четверг, 15 ноября 2012 г., 6:04:54 UTC+7 пользователь Adam Crabtree >>>> написал:
>>>>> @Alexey
>>>>> That looks nice, but the shortcoming of such solutions is the burden >>>>> of error handling falls on the library authors. Unfortunately, in my >>>>> experience, 3rd party module code failing is the most common source of >>>>> uncaughtExceptions. This makes perfect sense, since robustness comes after >>>>> feature-completeness. If I need a dropbox module, and am first >>>>> to implement one against their new REST API, I'll make sure it works for >>>>> 100% of my use cases, but not necessarily 100% of all use-cases (I'm a busy >>>>> man). Nonetheless, I would still open-source and fix any bugs that occur >>>>> (maybe).
>>>>> This is a common theme in node: unreliable 3rd-party libraries, and >>>>> the general advice is, make sure you trust their code like it was your own, >>>>> but that's a little silly considering we've just met; they seem trustworthy >>>>> and I need what they're selling... They may even be completely trustworthy, >>>>> but they have a masochistic penchant for throwing Errors in asynchronous >>>>> callbacks when a null response would be appropriate (think async version of >>>>> JSON.parse). I need to know when these failures occur so I can handle >>>>> and log them appropriately. Intentionally letting the server crash and >>>>> restarting is an absurd proposition.
>>>>> @Tim
>>>>> ATM, domains are easy to break. Here's a quick example of domains >>>>> failing when nested, whereas trycatch handles the error as expected. >>>>> Ideally, I'll eventually roll the domain resource management into trycatch, >>>>> but for now, they don't work for most of my use cases.
>>>>> Actually, Schoon tore all the old code out. ;P It's only still step in >>>>> the spirit of it being consecutive steps, for which you very much get >>>>> credit. =) You should take a look, it's dramatically different.
>>>>> Here's a quick list of added features:
>>>>> * Optional centralized async error handling
>>>>> * Short circuit to next step
>>>>> * Short circuit to callback on error or uncaught exception
>>>>> * Short circuit to callback
>>>>> * Errors on timeout for steps whose callbacks don't get called <- A >>>>> huge cause of unexpected "no server response" bugs
>>>>> * Generators for in-step callbacks (steps complete if non are >>>>> generated, regardless of return value) <- Allows for the base condition of >>>>> returning something (synchronously) in a step and not worrying about it >>>>> being undefined and the step not progressing
>>>>> * Explicit first variable, all arguments, event-style (no error) >>>>> callback support
>>>>> * No failure to progress if group generator not called
>>>>> * $.data shared between steps
>>>>> * Binding to event emitter events for callbacks
>>>>> * Composability
>>>>> * Dependency-injection style substeps via $.run (create a new set of >>>>> steps from within a step)
>>>>> Cheers,
>>>>> Adam Crabtree
>>>>> On Wed, Nov 14, 2012 at 11:12 AM, Tim Caswell <t...@creationix.com>wrote:
>>>>>> Adam, I'm glad you're still using that code! Out of curiosity, have >>>>>> you compared it to domains?
>>>>>> On Wed, Nov 14, 2012 at 11:57 AM, Adam Crabtree <atcra...@gmail.com>wrote:
>>>>>>> trycatch catches all uncaughtExceptions with long stack traces and >>>>>>> can be nested. We use trycatch in production at RedRobot (
>>>>>>> http://redrobot.com/), adding a great deal of stability and proper >>>>>>> error handling (500s). We also use it in conjunction with our control-flow >>>>>>> library stepdown which incorporates it at every "step" if it's installed.
>>>>>>> The following example catches and properly passes back all errors >>>>>>> generated both by it, passed to its callbacks, or uncaughtExceptions in >>>>>>> core or 3rd party module code complete with long stack traces, allowing you >>>>>>> to fail gracefully, ignore the error, or let it bubble.
