Re: Promises Programming Pattern Verification

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.

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.

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. As I'm implementing the spec, it appears to me that consistency suggests to strongly prefer exceptions over other error reporting mechanisms.

- WBR, Alexey Proskuryakov

Received on Tuesday, 12 November 2013 04:27:51 UTC