3 ms·

Dean Edwards on Callbacks vs Events

15 points by andreyf 18y ago

jerf 18y ago
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 18y ago
  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 18y ago
    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.
    - deleted 18y ago
      [deleted]
andreyf 18y ago
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 18y ago
  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".
  - mpk 18y ago
    If it's sequences you're looking for, try this technique I came up with a year or two ago, http://blog.mendix.com/?p=4 http://blog.mendix.com/?p=4 Doesn't use global variables and provides sequences that can be nested.
  - andreyf 18y ago
    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!

15 points by andreyf 18y ago

jerf 18y ago

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 18y ago
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 18y ago
  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.
  - deleted 18y ago
    [deleted]

andreyf 18y ago

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 18y ago
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".
- mpk 18y ago
  If it's sequences you're looking for, try this technique I came up with a year or two ago, http://blog.mendix.com/?p=4 http://blog.mendix.com/?p=4 Doesn't use global variables and provides sequences that can be nested.
- andreyf 18y ago
  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!