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
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
alexey.kupersht...@gmail.com wrote:
Any plans on making the long traces optional like trycatch(cb, cb2, true)
or probably configurable
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?
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() {
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
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 atcrabt...@gmail.comwrote:
More than a couple people mentioned try/catch not working in node.js in
the Fibers 0.5 thread (
@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
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
