

Dean Edwards on Callbacks vs Events - andreyf
http://deanedwards.me.uk/weblog/2009/03/callbacks-vs-events/

======
andreyf
_In a real [event] system, events are dispatched sequentially._

This seems off to me - if an explosion goes off, people's reactions will be
simultaneous, not sequential. Similarly, in an actor/event model (which is
what I'm thinking of) - when an event occurs, I would expect all objects
affected by said event to respond simultaneously.

~~~
Hexstream
I wonder if he was talking about:

Let's say some code executes which fires event EA. Then we go execute handlers
HA and HB for that event, in turn. But handler HA somehow triggers event EB
which has a handler HC that _depends on the state changed by HB_. But HB
hasn't fired yet because we're still in the HA handler. The illusion of
simultaneousness is violated and we're fucked.

The solution is to delay handling of events until all handlers for one
"generation" of events have been called.

edit: So maybe he meant "sequential" as in "not out-of-order".

~~~
andreyf
I'm not sure if I'm following... we've got:

    
    
        EA -> HA + HB
        HA -> EB -> HC
    

With HC expecting HB to have run. My reaction would be "don't do that". If HC
relies on HB completing, either put in a check in HC and keep trying until the
environment is right (write a higher-order function if you're doing it often),
or (better!) make your event system handle the logic you are trying to
describe: HC is triggered when both HA and HB complete, like so:

    
    
        EA -> HA + HB
        HA -> EB
        HB -> EC
        EB + EC -> HC
    

This is all trivial in JS, since handlers are just functions assigned to
variables!

------
jerf
Using try/catch does not imply that you must silently eat errors; in fact you
get arbitrary control over what to do with them, which I have often put to
good use. I would still prefer the try/catch solution, if it is browser-
compatible, on the grounds that it makes more sense if you just read it.

~~~
Gonsalu
The problem is that the try/catch part is implemented in the library.

It is impossible for library developers to know how it should handle your
exceptions, and you don't get to catch your exceptions, so there's no
advantage whatsoever in using the try/catch.

~~~
jerf
Sure you do. If you care about exceptions, your callback routines or event
handlers should use try/catch themselves. This is true regardless of the other
machinery; browser event handling or higher-level library, the upper layers do
not know what to do with a failing callback. Your objection is meaningless
because it's true independent of what is being discussed.

Furthermore...

    
    
          for (var idx in callback_array) {
             var callback_data = callback_array[idx];
             var callback = callback_data.callback;
             var error_handler = callback_data.error_handler;
    
             try {
               callback();
             } catch (err) {
               try {
                 error_handler(err);
               } catch (ignore) {}
             }
           }
    

there is nothing intrinsic about "not being able to handle your own errors",
either. (This is obviously simplified.) I don't think I'd implement, this,
though; I'd say if you want to handle exceptions, handle exceptions within the
callback.

Most implementations of callback loops suck, but this is the fault of the
implementors, not the idea.

