Re: [webpayments] PROPOSAL: The PaymentRequest object will not have code attached to it. It will be a pure data object. (#64)

> So a developer could, if they wanted, check the state before calling cancel, but if they don't, the system will just throw an exception.

This is exactly my point. Why do you need to expose the state information in this case if you can get an answer to the question by just trying to cancel and catching the exception? The developers code gets more complicated because now they have to check the state before canceling (note - they have to be /aware/ of the state and knowing when they can and can't cancel - added complexity), and they may even still need to do a try/catch block anyway because other things can cause an exception.

This is exactly the sort of stuff that XMLHttpRequest got wrong (be aware of state before calling certain methods, check state, but even when you do check state, things can still go wrong so you still have to try/catch).

---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webpayments/issues/64#issuecomment-174219732