-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to handle exceptions thrown in progress handlers? #136
Comments
Some options:
|
Here's a bit more about why rejecting the returned promise seems weird/dangerous to me. var p2 = p1.then(null, handleRejected, handleProgress); I think most people interpret Promises/A to mean that One might think that since Let's assume it works that way. I don't necessarily think it's wrong, but I think it creates some weird situations. For example: var pending = createPending();
var p1 = pending.promise;
var p2 = p1.then(handleFulfilled1, handleRejected1, function(update) {
throw new Error();
});
p2.then(handleFulfilled2, handleRejected2)
pending.progress('wat'); At this point, That leads to the obvious next question of what happens when the head does start to unwind? IOW, what should happen when This seems like a huge problem: No one can observe the result of I don't have any better options to offer right now, but just wanted to write down some of the potential pitfalls. |
Personally I'm not really a fan of adding progress as a third argument to |
This convinces me: the progress handler cannot control the state of the promise. Throw in |
WinJS swallows them, for the record. When.js propagates thrown exceptions as progress values. Dojo, from what I can tell by inspection, rejects |
Yeah, propagating the error was my short-term "solution", until we could figure out something better. We listed progress propagation as an experimental feature in a recent release. I'm beginning to think separating progress from |
I mean, it's a shame to have less features than any other promise library, even if those features are problematic. Q is, after all, the grandaddy of promise-libraries when it comes to features. Put another way, the reason I originally got off my butt and added promise support was because WinJS had it, and I needed to assimilate some WinJS promises with progress. I can imagine someone coming from jQuery and having similar sadness. @kriskowal any thoughts? |
BTW this is the last item on the 0.8.11 release list :). Once we figure it out we can move on to 0.9, i.e. the "kill all the deprecated methods!" release. |
I really don’t. I’ll defer to your judgement, @domenic. In the end, we will just need more practice with progress to get a better idea. I reserve the right to ax it outright in the future if it turns out that the feature is useless or hazardous. |
I'll try running it by the continuum then but my natural instinct is to throw in |
On Sat, Nov 24, 2012 at 5:05 PM, Domenic Denicola
|
My two cents: separate propagation from handling. The propagation API is then We should then discourage actually handling progress in the propagation handler, and instead have a separate As an alternative, axe propagation handling from promises altogether (except the most basic case). Instead, just forward progress evens if the var json = request('foo.com/file.json')
.then(function (res) {
return JSON.parse(res);
}, null, true); But ignores the case: var res = asyncOpA()
.then(function (res) {
return asyncOpB(res);
}, null, false); At that point we just say "You're on your own". But we let people do the propagation manually like so: var opA = asyncOpA();
opA.handleProgress(progressA);
var res = opA
.then(function (res) {
var opB = asyncOpB(res);
opB.handleProgress(progressB);
return opB;
}, null, false);
function progressA(val) {
res.emitProgress(val / 2);
}
function progressB(val) {
res.emitProgress(0.5 + val/2);
} The idea here is to do exactly what event emitters do, let an outside party add progress events into a promise, so that the consumer of a promise can still choose to make the promise emit progress events even if it wouldn't do so naturally. This has other nice use cases. Consider the case that you're given an API that returns promises, which don't support progress, but where you know approximately how long each async operation takes, you could add progress with something like: function addProgress(promise, expectedTime) {
var start = Date.getTime();
var int = setInterval(function () {
promise.emitProgress(Math.min((Date.getTime() - start) / expectedTime, 1));
}, 100);
promise.then(function () {
clearInterval(int);
}, function () {
clearInterval(int);
});
} |
They should presumably stop progress propagation, but how should they be reported?
The text was updated successfully, but these errors were encountered: