Try/catch not broken in node.js / How to properly handle uncaughtExceptions

[Adam Crabtree]

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

[Alexey Kupershtokh]

I published a similar module recently. I'm not the author though.

https://github.com/AlexeyKupershtokh/control-block/

Nice to see some advance in this direction :)

четверг, 15 ноября 2012 г., 0:58:43 UTC+7 пользователь Adam Crabtree написал:

[Tim Caswell]

Adam, I'm glad you're still using that code!  Out of curiosity, have you compared it to domains?

--
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 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

[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

--
Better a little with righteousness
       than much gain with injustice.
Proverbs 16:8

[Alexey Kupershtokh]

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 написал:

[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

[Alexey Kupershtokh]

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 написал:

[Adam Crabtree]

Yup. When I get the chance. Optionally also omit core and node_modules lines in the long stack traces.

[Alexey Kupershtokh]

Great.

I've posted an issue regarding that: https://github.com/CrabDude/trycatch/issues/15

воскресенье, 18 ноября 2012 г., 9:47:53 UTC+7 пользователь Adam Crabtree написал: