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 < [email protected]> 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: >> >> 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]> 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/**407539**9 <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/**for** >>>>>> um/?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/**tryc**atch<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/**step**down<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<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] > 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 > -- 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
