Live data from Hacker News

Error Handling in Node.js

joyent.com

61–70 of 96 posts

Re: Error Handling in Node.js

#61
post #52

Can anyone explain why this pattern doesn't work? Or point me to some resource? function myApiFunc(callback) { /* * This pattern does NOT work! */ try { doSomeAsynchronousOperation(function (err) { if (err) throw (err); /* continue as normal */ }); } catch (ex) { callback(ex); } }

Try/catch is not async and exceptions do not bubble up through the async context, which makes sense as the caller moved on with execution. Try this in your console:

    try {
        console.log("see, ");
        setTimeout(() => {throw new Error("oops")}, 100);
        console.log(
            "I can't assume here that"
            + " the prev. line succeeded"
        );
    } catch(e) {
        console.log("error!");
    }

Re: Error Handling in Node.js

#63
post #55

Earlier quoted context omitted.

Right! A long time back we came up with a really nice way of validating CSV files using restarts. I wrote a bit about it: http://lisper.in/restarts

Neat. I use it for things like linesearch and regularization (in optimization), https://github.com/matlisp/matlisp-optimization/blob/master/... As a fellow Indian lisper, are you by any chance using CL for work ? Last I heard, the only big CL shop, cleartrip, moved all their codebase to Ocaml.

Nah, not using CL for work these days :-(

I used to work at Cleartrip a long time back, before they moved off Lisp.

Re: Error Handling in Node.js

#64
post #55

Earlier quoted context omitted.

Neat. I use it for things like linesearch and regularization (in optimization), https://github.com/matlisp/matlisp-optimization/blob/master/... As a fellow Indian lisper, are you by any chance using CL for work ? Last I heard, the only big CL shop, cleartrip, moved all their codebase to Ocaml.

Nah, not using CL for work these days :-( I used to work at Cleartrip a long time back, before they moved off Lisp.

Ah, that's too bad :( CL is very very underrated as a language.

Any insider info on why cleartrip moved away from Lisp ?

Re: Error Handling in Node.js

#65
post #21

Earlier quoted context omitted.

What about auto-saving recovering data? It really depends upon the language and environment used. I work with C (almost legacy code at this point), and if the program generates a segfault, there is no way to safely store any data (for all I know, it could have been trying to auto-save recovery data when it happened). About the best I can hope for is that it shows itself during testing but hey, things slip into produc…

> I'm not a fan of defensive programming as it can hide an obvious bug for a long time (I consider it a Good Thing that the program crashed otherwise we might have gone months, or even years, with noticing the actual bug). I've had segfaults "hidden" for a long time because my artist coworkers weren't reporting crashes in their tools. They assumed a 5 minute fix was something really complicated. Non-defensive program…

Please, please, don't roll your own. It seems like an easy problem at a glance, but its far from it. The more fragmentation in these communities the worse off we all are. Sentry's totally open source, and we have generous free tiers on the hosted platform. Happy to talk more about this in detail, but if there's things you dont feel are being solved let us know.

Re: Error Handling in Node.js

#66
post #50

Earlier quoted context omitted.

Are you talking about things like EitherT? IMO here isn't so much of a difference to exception handling. Both approaches make it hard to see at a glance where most code could fail, and you can (but are not encouraged to) transform errors explicitly. Add Java's checked exceptions, now the practical differences are quite subtle. Of course it's nice to be able to be able to do transformations with higher level functions…

Standard "canned" reply: Java doesn't force you to annotate exceptions or even to handle them all. Typed returns do. And as to the "where", well, in the originating function. But that gets us to some real criticism here: You run the danger of getting an Either Monad out of about every function in your code-base... So maybe throwing exceptions isn't the worst thing after all. ( /me ducks all the stuff being thrown my…

Source? I was under the impression that it does (apart from things like NullPointerException, which of course has Haskell equivalents). And I've had to do a significant project in Java.

Re: Error Handling in Node.js

#67
post #21

Earlier quoted context omitted.

What about auto-saving recovering data? It really depends upon the language and environment used. I work with C (almost legacy code at this point), and if the program generates a segfault, there is no way to safely store any data (for all I know, it could have been trying to auto-save recovery data when it happened). About the best I can hope for is that it shows itself during testing but hey, things slip into produc…

> I'm not a fan of defensive programming as it can hide an obvious bug for a long time (I consider it a Good Thing that the program crashed otherwise we might have gone months, or even years, with noticing the actual bug). I've had segfaults "hidden" for a long time because my artist coworkers weren't reporting crashes in their tools. They assumed a 5 minute fix was something really complicated. Non-defensive program…

At work, we regard exception collecting as essential for both development and production - if an application reaches internal QA, it's already reporting to an exception collector. This is separate to whatever logging is going on.

Sentry.io is one of the services that we use, but I don't have any connection beyond being a customer. I would echo the sentiment about not rolling your own, though: you want your exception collector to be a thoroughly battle-tested bit of code, and if it's reporting to a remote service, you want that to be as separate as possible from the application infrastructure, and extremely reliable.

Re: Error Handling in Node.js

#68

Why the suggestion to use an error's name rather then instaneof and the error's class?

Error.prototype.toString() reads e.name, not e.prototype.constructor.name, so you can't rely on everyone to have subclassed Error. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

I'm not following, why can't I use:

   e instanceof Error
or:

   e instanceof MyError
why does toString() have anything to do with this?

Re: Error Handling in Node.js

#69
post #64

Earlier quoted context omitted.

Nah, not using CL for work these days :-( I used to work at Cleartrip a long time back, before they moved off Lisp.

Ah, that's too bad :( CL is very very underrated as a language. Any insider info on why cleartrip moved away from Lisp ?

Since it happened after I left, I am not privy to the exact reasons for the move. However, I guess they were worried about their Lispers moving away (which to some degree had already happened) and them not being able to find new ones.

Re: Error Handling in Node.js

#70
post #50

Earlier quoted context omitted.

Standard "canned" reply: Java doesn't force you to annotate exceptions or even to handle them all. Typed returns do. And as to the "where", well, in the originating function. But that gets us to some real criticism here: You run the danger of getting an Either Monad out of about every function in your code-base... So maybe throwing exceptions isn't the worst thing after all. ( /me ducks all the stuff being thrown my…

Source? I was under the impression that it does (apart from things like NullPointerException, which of course has Haskell equivalents). And I've had to do a significant project in Java.

You mean Unchecked Exceptions (that extend from RuntimeException) vs Checked Exceptions?
Post reply on HN