Calling event listeners separately, instead of calling them sequentially about eventemitter2 HOT 12 CLOSED

cool, if you can give me a proof of concept on how setTimeout can contain exceptions i'll bake it in ;) otherwise, try/catch is pretty slow.

from eventemitter2.

i was going for something like this: https://gist.github.com/1029170

Running this in the browser (latest Chromium build) results in a "will show" console log, together with a log of an uncaught exception.

However, surprisingly for me, running this in Node (0.5pre) will result only in the process terminating together with a log of the exception (the "will show" doesn't show up). I wrongly assumed that node handles uncaught exceptions the same as the browser does i.e. that it doesn't kill the event loop if more events are to be processed.

After a bit of Googleing, I've found that several other people are not happy with this behavior in Node, but this is how it is. The "fix" is to use process.on('uncaughtException', function (err) { ... }); to handle these exceptions which will keep the event loop alive to invoke the other listeners.

But I guess all of this is not news to you and I'm just re-discovering the broken wheel here :D

from eventemitter2.

try/catch has a lot of overhead, but it is really the most straight forward option. i'd love to hear more peoples thoughts on this though.

from eventemitter2.

What's the correct behavior with throwing errors? Is it like Chrome does, continue execution or should the process be fully terminated like in Node?

from eventemitter2.

Not sure if there is a single correct or agreed upon behavior... I tried asking in the node.js IRC channel (http://nodejs.debuggable.com/2011-06-16.txt -- search for izuzak) but got a response that NodeJS isn't a browser and that the most sensible action in case a single uncaught exception occurs is shutting down the server. I don't agree with that and I'm not sure what the reasoning is behind that design decision.

from eventemitter2.

normal programming convention is that if your program throws an error and you don't catch it, it is considered fatal and it should exit. This is because if you know an error may occur, you would have either prevented it, or caught it with a try/catch.

I think EE2(EventEmitter2) should not deviate too far from how EE works, and whoever is creating the callback should have a try/catch on their side otherwise it would imply your program has unexpected behaviour.

from eventemitter2.

@DrJackal -- I agree - whoever is creating callbacks should have a try/catch on their side. But, nevertheless, I think the issue is more general, and in essence -- my argument is not against EE2, it's against the current way NodeJS handles uncaught exceptions.

Does an OS exit if a single application throws a divide-by-zero exception? No, it kills the app and keeps the other apps running. The same thing happens in a browser.

In other words, it's not the EventEmitter that throws an exception, it's a listener that throws an exception. And in that case - the listener should crash (since it didn't have a try/catch to prevent the error), but the emitter and other listeners shouldn't. It's not that that the developer of EventEmitter would have prevented an error, rather it's that a single listener doesn't care if an error happened in another listener. Again - does your code editor care if your browser crashes? No, it happily carries on because the underlying engine (the OS) didn't crash.

Node shouldn't kill the event loop only because a single event throws an exception.

from eventemitter2.

a better analogy for NodeJS's error handling would be, if an OS(NodeJS) component, say graphics driver (http.server) threw an error, if there is no known way to recover from the error (try/catch), then the only reasonable behaviour would be to stop(blue screen) and inform the operator of a error that may spread and cause permanent errors (say in a database).

Again Node should kill the event loop not because a single listener threw a exception but because node has no way to know if that error leads to pervasive problems for following listener/instance.

This is not unique to NodeJS, other languages like python, Matlab (whatever this is in), Java, C, follows this behaviour pattern, uncaught exceptions may be an indicator to a more system wide problem and should force the program to quit.

from eventemitter2.

you're right -- it is a better analogy for Node. but I'm not sure it's a good analogy for EE. in EE - the listeners should be mutually decoupled and decoupled from the EE, right?. bringing us again to the solution of wrapping each listener invocation in a try/catch block.

plus, what's your take on browsers behaving differently with uncaught exceptions (they don't kill the event loop)? what's the essential difference?

from eventemitter2.

Not necessarily can a listener be decoupled from the EE, e.g. a listener that removes itself (or other listeners), even on error of the remover you end up with execution of listeners that should never fire because of an error.

This produces the unexpected behaviour (existence of other listeners) due EE executing listeners asynchronously, and not even a try-catch block can save you in this case.

This is something similar to why require() is synchronous vs asynchronous (you have to wait until everything is loaded anyways, because missing and required file should make you exit the program).

I believe the browser side has automatic try-catch blocks for uncaught errors (or everything) since Mozilla would not want people to start filing bug reports for every site with a bad line of javascript (making the tab close). This should be why event loops continue through even though on the server side they wouldn't.

from eventemitter2.

Jumping in real quickly here...

@izuzak, you said: Node shouldn't kill the event loop only because a single event throws an exception.

I disagree with that assertion. If an error occurred that has not been trapped properly, the state of your application has become indeterminate. Continuing to run your application in an indeterminate state can yield extremely unexpected behavior.

from eventemitter2.

we will keep the implementation inline with EE in core, marking as closed.

from eventemitter2.