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:
>
> 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 <
> [email protected] <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.
>>>
>>> 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 <[email protected]>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]>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 [email protected]
>>>>>
>>>>> 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 [email protected]
>>>>
>>>> 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 [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
