Card: Remove try/catch from Vault Flow

[sshropshire]

Summary of changes

• This PR removes try/catch from CardClient.vault()
• To do this, we've refactored UpdateSetupTokenResult to make it a sealed class with .Success and .Failure subclasses
• Using "Result" types cleans up the codebase by providing compile time support for error handling
• This is a follow up PR to Card: Remove try/catch from Approve Order Flow #302

Checklist

• Added a changelog entry

Authors

List GitHub usernames for everyone who contributed to this pull request.

• @sshropshire

[KunJeongPark]

Are you going to do this for all the API calls? It's an interesting pattern. I'm thinking about this for iOS.
Not sure if it works with async/await pattern in iOS. It'd be weird, to have do catch block and non throwing function that returns Result type. It takes away advantage of error propagation in iOS async/await.

But I see that's similar to what you are doing here. You have try/catch block that returns a result type.

I think you had mentioned that you were going to remove listener pattern eventually.
So the merchant would receive the result type as well?

[sshropshire]

@KunJeongPark yes for Kotlin it's considered a best practice. Honestly I'm not sure this will be needed for iOS though. Swift does have checked exceptions i.e. when you call code that throws you have to surround it with do/catch in order for compilation to succeed. On Kotlin the compiler doesn't even warn us when we call throwing code without exception handling, and that's the primary reason we need a pattern like this on Android to make sure we have compiler enforcement.

[KunJeongPark]

Could it throw other exceptions?

[sshropshire]

That's a good question. I took a thorough tour of the docs and here are all the methods called:

• Context#getResources() does not throw
• Resources#openRawResource() throws Resources.NotFoundException
• InputStream#available() throws IOException
• ByteArray() does not throw
• InputStream#read() throws IOException, NullPointerException
• InputStream#close() throws IOException

According to the docs InputStream#read() will only throw if resAsBytes is null, and through Kotlin we have guarantees that it is non-null. All the other possible exceptions we've caught.