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
>
> 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
> <[email protected]<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
>> <[email protected]<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:
>>>
>>> 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
>>>
>>> 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
>>> You received this message because you are subscribed to the Google
>>> Groups "nodejs" group.
>>> To post to this group, send email to [email protected]<javascript:>
>>> To unsubscribe from this group, send email to
>>> [email protected] <javascript:>
>>> For more options, visit this group at
>>> 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
>> You received this message because you are subscribed to the Google
>> Groups "nodejs" group.
>> To post to this group, send email to [email protected]<javascript:>
>> To unsubscribe from this group, send email to
>> [email protected] <javascript:>
>> 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
