There's no real good answer here. From a practical standpoint, I'd say the
because the code paths for 'the user said yes' and 'the user said no', are
often completely exclusive, you should reject on a no response, and just
use a dummy rejection handler when the code paths would converge (or at the
end of the chain if that never happens).
Note: there's nothing wrong with not handling a rejection, and the dummy
rejection handler is a solution to a problem of the solution to silent
failures. By doing this, you're reinstating the problem of silent
failures, even when caused by the programmer (see code below).
The second solution is to encode the answer in the resolution, and only
reject if e.g. the question is unable to be asked (because it comes from a
server endpoint which gives a 503, or whatever). This option mostly makes
sense if you're done with promises, check the resolution value, and branch
out into code that doesn't need to report its status back. Show an error
message if the promise was rejected. You can do the same by pattern
matching on the rejection reason (example in bluebird):
wairForUserConfirm('Continue to exit?')
.catch(ServerError, (e) => {showErrorToUser(e); throw e})
.then(exitApplication)
.catch(Modal.Cancel, noop) // handle this 'Error', but not e.g.
ReferenceError, TypeError
As with anything: consider 'which will make my code easier to read and
maintain', make an educated guess, and do it!
On Sun, Feb 1, 2015 at 2:55 AM, Gray Zhang <[email protected]> wrote:
> Recently I was reviewing my code repository and the useless of Promise, I
> found we have majorly 2 scenario to use Promise:
>
> 1. Just match the synchronous flow control, so then matches return and
> catch matches catch
> 2. Use it for a yes-or-no scenario, this is what I’m confusing
>
> For the 2nd scenario, a best example should be a confirm dialog, which
> returns a Promise which resolves after user click the “YES” button and
> rejects after the “NO” button is clicked, so the usecase could be:
>
> var confirming = wairForUserConfirm('Continue to exit?');
> confirming.then(exitApplication);
>
> I see it a “reasonable” scenario, in this case the resolve means *user
> resolves your question* and reject means *user rejects*, seems a good
> story up to now
>
> The problem is, in such case we usually do not attach a catch to
> rejections, once the global uncaught exception handling for promise is
> done, it may throw a window.onerror message which is not expected
>
> Therefore, I’d like to ask whether we should ONLY use Promise as a
> return-or-throw synonyms, or we should use it in a yes-or-no scenario
>
> Thanks
>
>
> _______________________________________________
> es-discuss mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss
>
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
