Should exceptions in requestors be special?

[nekdolan]

The documentation states that A requestor should not throw an exception. It should communicate all failures through its callback. which is understandable, however the code will catch exceptions and use them as the reason for the failure. This also makes sense since async code should not be allowed to throw in production, but I would disagree that the same is true for development. While it is true that a requestor function should not throw, that is not something that is always under our control since a mistake could easily cause the code to throw especially during development. Perhaps it would make sense to throw the reason after parseq has finished its task, so that we can crash the app. Maybe it would make sense to add an attribute to the reason that was caused by an exception so that we have the option to handle it differently than a normal failure. For example:

} catch (exception) {
  exception.thrown = true; // set attribute so that we can detect it later
  action(undefined, exception, number);
  number = undefined;
  start_requestor(value);
}

[douglascrockford]

Please let me know if this turns out to be a real issue.