RE: Promises Programming Pattern Verification

On Monday, November 11, 2013 8:27 PM, Alexey Proskuryakov wrote:
> 11 ΞΟΡΒ. 2013 Η., Χ 19:47, Israel Hilerio <israelh@microsoft.com> ΞΑΠΙΣΑΜ(Α):
> 
> > Also, per our previous conversation (a couple of weeks back) the expected
> >error handling is ideally exception free and relies on the promise failure handler
> >model (EXAMPLE1).  In this model, all error handling can be done inside the
> >failureFunctionPromise1() function vs. the exception based pattern outlined in
> >EXAMPLE3 which breaks the error handling into two blocks (exceptions vs.
> >failed promises):
> 
> Could you please provide a pointer to the previous discussion? I joined the WG
> recently, and when reading earlier posts, I only saw some discussions that
> seemed to lack a consensus resolution.

Here is the previous thread discussing this topic [1].  The reason I'm bringing this up is to figure out if consensus can be achieved.  My recollection of the last conference call was that we were going to explore this idea and discuss it at the face to face.

> It is not clear to me why late detection of errors is better than early detection.
> There is considerable infrastructure for working with exceptions - e.g. JS
> debuggers will stop on uncaught exceptions, helping one easily discover what
> went wrong. If an exception went uncaught, many advanced web applications
> catch it with window.onerror, and report home for offline investigation.
> 
> To the contrary, a failed promise just fails silently, and even if you handle that,
> all you get is likely a null result with no explanation whatsoever.

As Promises continue to move forward, we will have to build better tools to support debugging of promises.

I believe that no matter the reason for the operation failure (early or late detection), you won't be able to recover very easily from an exception or a failed promised.  So it seems like it could be easier to unify the models in order to collocate the cleanup code and simplify the programming model.  I understand there are things like TypeErrors and other possible WebIDL error conditions that could throw exceptions.  My question is whether this is something we could consolidate.  In addition, you could pass the reason for the promise rejection as a parameter to the failure function which could give you insights into the reason for the failure.

> 
> Also, handling exceptions is necessary in any case, as ones may be raised by
> WebIDL algorithms. Extending this unavoidable behavior, errors during JWK
> type conversion aren't that different, so I would expect to get exceptions there
> too. 

My understanding is that if you throw an exception inside the promise success handler, this could cause the promise to fail and could trigger the Promise failure handler.  If this is true, then you could already handle errors this way without having to catch the exception.  Perhaps, I misunderstood this.

> As I'm implementing the spec, it appears to me that consistency suggests
> to strongly prefer exceptions over other error reporting mechanisms.

The reason I bring this up is to try to better understand the programming patter we would like to propose.  Perhaps like you suggest, it has to be a mixture to deal with WebIDL parameter failures like with do today between ErrorEvents and Exceptions and Promises are just another extension of that pattern.  I'm  just curious if combining the two models doesn't simplify the model.   

> - WBR, Alexey Proskuryakov
Israel

[1] http://www.w3.org/2013/10/28-crypto-minutes.html

Received on Tuesday, 12 November 2013 06:42:04 UTC