Handling progress handler exceptions

[briancavalier]

See #1 and #2

If we allow throwing a "stop propagation" error, what do we do with other exceptions thrown by progress handlers?

[domenic]

Previous discussions:

• https://groups.google.com/d/topic/cujojs/QurUiAeTa5E/discussion
• How to handle exceptions thrown in progress handlers? kriskowal/q#136
• https://groups.google.com/d/topic/q-continuum/QmhN6prhtUw/discussion

[ForbesLindesay]

You could let the person triggering the progress event decide:

function progressProducer() {
  let [resolver, promise] = defer();
  let i = 0;
  setInterval(function () {
    resolver.progress(i++)
      .then(null, function (err) {
        //handle error from progress handlers
      });
  }, 100);
  return promise;
}

progressProducer()
  .then(null, null, function (prog) { throw new Error('progress handler throwing exception'); });

Essentially the call to emit progress would return a promise for an array of the results of all progress handlers. This would suit me quite well as I currently have a project where I really want to wait till the (asynchronous) progress handlers have completed before continuing.

[domenic]

@ForbesLindesay that is a fascinating idea. It introduces a lot of subtleties regarding chaining and the like, I'm sure, but I'm impressed and generally for it.

[ForbesLindesay]

@domenic thanks, the crazy thing is that I didn't think of that as an option at any point when writing my article detailing my thoughts. It just didn't occur to me until I realised I had an app that needed to actually do something with the partial results of an asynchronous operation, before letting the async operation continue.

[blai]

I think @ForbesLindesay 's solution make sense, here's how I see it:

----------------------------------------------------------------------------------------
initial state                 resolving state             terminal state
---------------------------------------- time ---------------------------------------->
process start
                       progress (a step is resolved)
                                                                   process resolved

OR case 2

process start
                       progress (a step failed)
                       progress (failed step recovered)
                                                                   process resolved

OR case 3

process start
                       progress (a failure step)
                                                                   process failed

In case 2, failed step recovery could be built-in as part of the original process, or it could be done in one of the process handler. If I understand correctly, in @ForbesLindesay 's case, user who defined a progress handler might have the intention to respond to a change (maybe as an attempt to recover a failed step) before the process move onto next step. It seems like promise.then(resolveHandler, failHandler) should be separated from promise.progress(stepResolveHandler, stepFailHandler). Also, when a promise is implemented to notify the status of an intermediate step, and promise.progress() is defined, it should work like yield in ES6 (harmony).

Just some random thoughts