whats the problem? if you want to change the halting you have option 4. assign a handler to process.on 'unhandledException' and override standard behaivor: http://nodejs.org/api/all.html#all_event_uncaughtexception 5. run your app in a domain and handle all your "knownly ignored error events" here at once: http://nodejs.org/api/all.html#all_domain
:) Am Samstag, 29. Dezember 2012 21:02:45 UTC+1 schrieb Jeff Lee: > > A modest proposal: throwing errors on uncaught 'error' events in > EventEmitter should be made optional, rather than mandatory. > > Looking back at the original thread that proposed the throwing behavior ( > https://groups.google.com/d/topic/nodejs/7BU_1BB9zeM/discussion), I'm > surprised at how little debate there was about adding built-in special-case > events to a general library class. The throwing behavior seems like an > abstraction flaw. Event handles are an "userspace" concept, and the > lib/runtime shouldn't be imposing semantics on that. In particular, 'error' > is a very generic term, and useful enough that it ought to be reserved for > whatever the app intends for it. > > For example, I might have an app that produces "success" or "error" > events. The "error" events may even be anticipated and normal within the > concept space of the app. They may be being broadcast simply for logging > hooks--if I care to log "error" events, I'll listen for them, but if I > don't care, I shouldn't be required to install a listener to prevent the > app from halting. You might argue that I should rename the "error" event to > "failure" or some other term, but that seems awfully heavy-handed. If > variable naming truly is one of the hard problems of computer science, then > event naming is similarly difficult, and as such it's a little rude for the > API to impose any restrictions, especially for such a semantically > ambiguous term. > > Of course, it's probably not feasible at this point to remove throwing > behavior from the API entirely, but it seems fairly easy to change it to a > switchable default. One could imagine a lot of different ways of > implementing this using module-level configuration: > > 1. A simple on/off boolean property > 2. A method that lets you set the name of the 'error' event, or blank if > you don't want the automatic throwing > 3. A method that lets you set a common callback for all emitters that > aren't handling 'error'. > > Personally, I prefer some combination of 2 and 3. In any case, if there's > interest from the community, I'd be happy to contribute a pull request for > this. > -- 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
