Streamline question: callback errors

29 views
Skip to first unread message

Aseem Kishore

unread,
Oct 8, 2012, 6:22:15 PM10/8/12
to stream...@googlegroups.com
Hey Bruno et al.,

A developer who uses one of my Streamline projects emailed me with a really interesting issue: if he calls the Streamlined API from non-Streamline code, and a callback from his side throws an error, Streamline ends up re-calling that callback (this time with an error argument).

Here's a simple example -- plug this into the online demo and and press "execute" to see the callback get called twice:

function foo(_) {
  setTimeout(_, 1000);
  return 'good';
}

foo(function (err, res) {
  alert('called with err=' + err + ' and res=' + res);
  throw new Error('foo');
});

This behavior took him by surprise because he (probably correctly) assumed that any errors his callback got were from *my* code and not his. And in this case, the errors thrown were AssertionErrors from test code.

His suggestion was that if a callback throws an error, Streamline should probably just re-throw it and let it propagate up to fail-fast/crash. That sounds like a great suggestion to me, but I'm not sure if you've thought about this deeper than we have and have a conscious reason for the current behavior. =)

What do you think? Thanks as always for the great work and consideration!

Cheers,
Aseem

Bruno Jouhier

unread,
Oct 9, 2012, 4:25:37 PM10/9/12
to stream...@googlegroups.com
Hi Aseem,

This is a tricky one. I may be able to fix it but this can be a bit hard. The problem is that I have to catch exceptions in callback stacks to ensure that all exceptions (the ones that are thrown explicitly by new Error(...) as well as the ones that are thrown implicitly by bugs) are correctly propagated to catch clauses. To fix it I'll need to distinguish between callbacks that have been generated by streamline and callbacks that have been written by a developer. A bit tricky but probably feasible.

Note that the problem is also related to the fact that the developper was lousy with error handling. He should be testing the err parameter and do something like

foo(function (err, res) {
  if (err) throw err; // or pass it to another callback
  alert('called with err=' + err + ' and res=' + res);
  throw new Error('foo');
});

Then, the problem goes away.

So I should probably document this until it gets fixed.
Reply all
Reply to author
Forward
0 new messages