this.props.stripe.createToken({name,address_line1, etc})
.then (result=>{console.log(result)})
.catch((err)=> {console.log(err)});
does not catch any form validation error. instead it returns an error object within the .then statement in the form of result.error.
Is this behaving as expected? I can work around it by putting my error handling in the .then(result) but it seems silly to me.
https://stripe.com/docs/stripe-js/reference
just found the documentation i guess it is behaving as expected
Yep, this is as expected!
We explicitly want you to handle the errors when the Promise resolves. Since the shape of result can be either {error: {...}} or {token: {...}}, you must condition over it and explicitly handle the error. If we had just thrown an error, many developers may not add a .catch() and ignore the error altogether.
Another reason for this behavior is that it makes using async/await syntax easier. Currently you can do:
const {error, token} = await this.props.stripe.createToken(...);
if (error) {
// Handle error
} else {
// Charge token...
}
If we had thrown an error, you would have to use try-catch, which is less than elegant, and also suffers from the problem that many developers may forget to handle the error.
try {
const token = await this.props.stripe.createToken(...);
} catch (e) {
// Handle error
}
Our belief is that this approach makes for a safer, more explicit integration. If you have feedback though, please let us know!
(Note also that this matches the behavior of another popular Promise based API, fetch().)
@atty-stripe thank you so much for taking the time to explain that async/await decision! 馃憤 馃挴
This surprised me. I end up with Stripe calls being the only code that handles errors within the resolution of a promise as opposed to the catch, but oh well 馃憤
try {
const { error, token } = await this.stripe.createToken(cardNumber)
if (error) throw error
...
} catch (err) {
this.error = err.message
}
Most helpful comment
Yep, this is as expected!
We explicitly want you to handle the errors when the Promise resolves. Since the shape of
resultcan be either{error: {...}}or{token: {...}}, you must condition over it and explicitly handle the error. If we had just thrown an error, many developers may not add a.catch()and ignore the error altogether.Another reason for this behavior is that it makes using
async/awaitsyntax easier. Currently you can do:If we had thrown an error, you would have to use try-catch, which is less than elegant, and also suffers from the problem that many developers may forget to handle the error.
Our belief is that this approach makes for a safer, more explicit integration. If you have feedback though, please let us know!
(Note also that this matches the behavior of another popular Promise based API,
fetch().)