2

I'm reading about error handling in nodejs, and I came across something unsettling while reading this document:

http://nodejs.org/api/domain.html

It says "By the very nature of how throw works in JavaScript, there is almost never any way to safely "pick up where you left off", without leaking references, or creating some other sort of undefined brittle state."

This sounds horribly horrible. Is this really saying that any time an exception is thrown, I need to shut down the thread? I feel like I'm missing something here.

B T
  • 57,525
  • 34
  • 189
  • 207
  • throw if it's a developer error. otherwise, pass it through a callback or emitter. – Jonathan Ong Apr 10 '13 at 04:55
  • 1
    possible duplicate of [Why would an exception cause resource leaks in Node.js?](http://stackoverflow.com/questions/15825752/why-would-an-exception-cause-resource-leaks-in-node-js) – Asad Saeeduddin Apr 10 '13 at 05:09
  • Indeed it is, thanks Asad. What should I do with this question since it's a duplicate? – B T Apr 10 '13 at 05:30
  • Note that my answer at this page covers my current understanding of the answer to this question: http://stackoverflow.com/questions/15825752/why-would-an-exception-cause-resource-leaks-in-node-js – B T Apr 11 '13 at 05:40

1 Answers1

3

There's nothing wrong with throwing exceptions in the right circumstances. It is a useful tool and can be used as such. Exceptions are generally not the right tool for normal, expected, frequently used code paths because they are slow, much slower than normal return values. It's usually better to use return values for those types of circumstances if performance matters to you.

But, exceptions can significantly simplify your code for unexpected error conditions or non-normal conditions and, in a memory managed language like javascript, you generally don't have to worry about memory leaks when throwing an exception except if you are in the middle of manipulating persistent global state when you throw the exception. All local variables and their references are cleaned up for you when an exception is thrown when they go out of scope.

Exceptions don't lead to memory leaks or a brittle state unless your code is poorly written which is the same for any other method of indicating an error condition.

jfriend00
  • 683,504
  • 96
  • 985
  • 979
  • "Leaking references" is not the same as "leaking memory". – Asad Saeeduddin Apr 10 '13 at 05:03
  • @Asad - what is "leaking references" then? – jfriend00 Apr 10 '13 at 05:03
  • Bringing variables into a scope they weren't intended to be accessed from, I believe. – Asad Saeeduddin Apr 10 '13 at 05:04
  • 1
    @Asad - nothing like that happens when you throw an exception. Javascript is strictly scoped. Throwing an exception doesn't change the scope availability of any variable. – jfriend00 Apr 10 '13 at 05:05
  • I can't agree with the statement that its "better to use return values". That is some archaic thinking. – B T Apr 10 '13 at 05:31
  • @BT - exceptions in javascript do not perform well (e.g. they're many times slower than using return values) so you may not want them in your normal expected code flow. That's not "archaic" - that's practical. Did you downvote? – jfriend00 Apr 10 '13 at 05:37
  • "Expected errors" may not have conveyed what you meant. Your code shouldn't usually be regularly doing stuff that causes errors, whether or not you consider them "expected". When an operation fails, exception handling is far superior to passing around error codes and the like. I did downvote - even if its not what you meant, your answer will mislead people into thinking they shouldn't be throwing exceptions in javascript. I'll remove the downvote if you edit the answer to clarify what you mean by "expected errors". – B T Apr 10 '13 at 06:04