Skip to content
This repository
Browse code

doc: advise *strongly* against uncaughtException

  • Loading branch information...
commit e8af3405574dfee2cb8c11bf27195b774332db96 1 parent e1fb7b7
Ben Noordhuis authored July 18, 2012

Showing 1 changed file with 12 additions and 3 deletions. Show diff stats Hide diff stats

  1. 15  doc/api/process.markdown
15  doc/api/process.markdown
Source Rendered
@@ -43,10 +43,19 @@ Example of listening for `uncaughtException`:
43 43
     console.log('This will not run.');
44 44
 
45 45
 Note that `uncaughtException` is a very crude mechanism for exception
46  
-handling.  Using try / catch in your program will give you more control over
47  
-your program's flow.  Especially for server programs that are designed to
48  
-stay running forever, `uncaughtException` can be a useful safety mechanism.
  46
+handling and may be removed in the future.
49 47
 
  48
+Don't use it, use [domains](domain.html) instead. If you do use it, restart
  49
+your application after every unhandled exception!
  50
+
  51
+Do *not* use it as the node.js equivalent of `On Error Resume Next`. An
  52
+unhandled exception means your application - and by extension node.js itself -
  53
+is in an undefined state. Blindly resuming means *anything* could happen.
  54
+
  55
+Think of resuming as pulling the power cord when you are upgrading your system.
  56
+Nine out of ten times nothing happens - but the 10th time, your system is bust.
  57
+
  58
+You have been warned.
50 59
 
51 60
 ## Signal Events
52 61
 

7 notes on commit e8af340

Brian White

So if uncaughtException may be removed in the future, does that mean every node.js process will have at least 1 domain?

If so, I was under the impression domains had some kind of performance penalty? If not, it seems like dropping uncaughtException gives us no control over what happens when something blows up (by default)?

Ben Noordhuis

So if uncaughtException may be removed in the future, does that mean every node.js process will have at least 1 domain?

Perhaps - details are TBD. uncaughtException is beyond redemption though, it's fundamentally broken.

If not, it seems like dropping uncaughtException gives us no control over what happens when something blows up (by default)?

You say that as if it's a bad thing. :-)

Shigeki Ohtsu

@bnoordhuis I think that one of alternatives is to introduce globalDomain like

var globalDomain = require('domain').globalDomain;
globalDomain.on('error', function(e) {
  console.log(e.message);
});
function f() {
  throw new Error('foo');
}
f();

This can be easily implemented as

--- a/lib/domain.js
+++ b/lib/domain.js
@@ -30,7 +30,7 @@ var endMethods = ['end', 'abort', 'destroy', 'destroySoon'];
 // communicate with events module, but don't require that
 // module to have to load this one, since this module has
 // a few side effects.
-events.usingDomains = true;
+events.usingDomains = exports.usingDomains = true;

 exports.Domain = Domain;

@@ -253,3 +253,15 @@ Domain.prototype.dispose = function() {
   // so that it can't be entered or activated.
   this._disposed = true;
 };
+
+Object.defineProperty(exports, 'globalDomain', {
+  get: function() {
+    var globalDomain = new Domain();
+    if (exports.active) {
+      stack.push(globalDomain);
+    } else {
+      globalDomain.enter();
+    }
+    return globalDomain;
+  }
+});

How do you like it?

Isaac Z. Schlueter
Collaborator

Since domains is still an experimental feature, I'd prefer not to force it on people just yet. We're still working out bugs and odd edge cases, and might change its behavior significantly in 0.9, depending on what we learn from people using it over the next few months.

Ben Noordhuis

@shigeki Looks like a reasonable approach to me.

[EDIT: hadn't noticed that @isaacs already commented.]

Shigeki Ohtsu

@isaacs The change of document in this commit indicates to use domain instead of uncaughtException event. I think we should provide alternative solutions to make the most use of domain.

weepy
weepy commented on e8af340 July 26, 2012

uncaughtException is useful for doing things to log exception, otherwise you don't know why something died

  process.on('uncaughtException', function(e) {
    log(e)
    process.exit()
  })
Please sign in to comment.
Something went wrong with that request. Please try again.