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.
>>
>> https://gist.github.com/**4075399 <https://gist.github.com/4075399>
>>
>> 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:
>>>
>>>> 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<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:
>>>>
>>>> https://npmjs.org/package/**trycatch<https://npmjs.org/package/trycatch>
>>>>
>>>> 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 readme's out of date, so checkout the passing tests)
>>>> https://npmjs.org/package/**stepdown<https://npmjs.org/package/stepdown>
>>>>
>>>> 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)
>>>> }
>>>>
>>>>
>>>> Cheers,
>>>> Adam Crabtree
>>>>
>>>> --
>>>> Job Board: http://jobs.nodejs.org/
>>>> Posting guidelines: https://github.com/joyent/**node/wiki/Mailing-List-
>>>> **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 nod...@googlegroups.com
>>>>
>>>> To unsubscribe from this group, send email to
>>>> nodejs+un...@**googlegroups.com
>>>>
>>>> For more options, visit this group at
>>>> http://groups.google.com/**group/nodejs?hl=en?hl=en<http://groups.google.com/group/nodejs?hl=en?hl=en>
>>>>
>>>
>>> --
>>> Job Board: http://jobs.nodejs.org/
>>> Posting guidelines: https://github.com/joyent/**node/wiki/Mailing-List-*
>>> *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 nod...@googlegroups.com
>>>
>>> To unsubscribe from this group, send email to
>>> nodejs+un...@**googlegroups.com
>>>
>>> For more options, visit this group at
>>> http://groups.google.com/**group/nodejs?hl=en?hl=en<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 nodejs@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+unsubscr...@googlegroups.com
> 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 nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
