Great. I've posted an issue regarding that: https://github.com/CrabDude/trycatch/issues/15
воскресенье, 18 ноября 2012 г., 9:47:53 UTC+7 пользователь Adam Crabtree написал: > > 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] <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: >>> >>> 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]<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
