Open ForbesLindesay opened 11 years ago
From my comment in #2:
The concept is interesting, indeed. I'm not caught up yet on the Hot and Cold promises thread, but my initial reaction is that lazy promises are something that could easily be built on top of a current Promises/A+ promise. It feels weird to me initially to have this integrated this directly into Promises/A+ promises as they exist today.
@ForbesLindesay note that this is exactly what gozala/recuders does.
I sometimes fall in to the trap of not calling the reducers equivelant of done
but this is a lot less annoying then done
not throw the exception. gozala/reducers has a PR for making it's equivelant of done
throw which is important enough that I use that branch to develop against because having objects with boxed / hidden errors inside of them is frustrating to no end.
Coming from node callbacks and event emitters I find their error handling correct. Event emitters throw if I don't handle it. callbacks push the error directly in my face every single time.
Reducers has a very similar model to streams, if you start the stream by folding (equivelant of .done
) then it will throw any errors it finds so you better handle them
@briancavalier Yes, hot and cold promises could be built directly on top of the current promises/A+ spec and would indeed still be valid promises (providing calling .then
made the promise execution start). The issue is that doing it that way would not help deal with unhandled rejections. By making hot/cold promises that start when .done
is called, we would effectively nullify the whole unhandled rejection problem.
Ass suggested by @Raynos in #2 we could make promises lazy until
.done
is called. Consider thepromise(executor)
syntax being proposed in https://github.com/promises-aplus/resolvers-spec/issues/3The executor is a function which initiates the asynchronous operation. It has the potential to generate either a resolved promise or a rejected promise. If it's not called, then no rejected promise can exist, so we don't have an issue. So the key idea being presented here is to only call it when we know the promise's rejection will be handled.
By only calling the executor once
.done
is called, you can guarantee that.done
will always be called for all promises. If.done
is not called, the entire function will fail to do anything, which will be easy to quickly pick up when developing.Having done that, it's a simple case of having
.done
behave as in #5 and crash the application appropriately by throwing the exception in the next turn of the event loop.Transition
Step 1, ad
.done
to the promises spec.Step 2, make sure all promise libraries call
.done
if present when assimilating promises.Step 3, wait a month or so for this to be true of most major promise libraries
Step 4, begin using
console.warn
to warn people that they need to begin calling.done
when.done
is not called after a period of a few seconds.Step 5, Implement this feature properly by making the promises lazy.