Add ability to map AWSMobileClientError to underlying string message

[medvedNick]

I'd like to show user-friendly error messages received from AWSMobileClient. For instance,

AWSMobileClient.sharedInstance().signUp(username: loginInfo.phone, password: loginInfo.password) { signUpResult, error in
    // error is an AWSMobileClientError with associated message
....

I can add long switch-case for AWSMobileClientError enum or add the following check:

if let .usernameExists(message) = error {
    showAlertWithMessage(message)

but it would be great to have something like ErrorMappingHelper but for the opposite direction, which will convert AWSMobileClientError to string message and will be ready to be used out-of-the-box

[mutablealligator]

Thank you @medvedNick for reporting to us. @rohandubal will be reviewing the PR #1270 and will provide updates soon.

[rohandubal]

Hello @medvedNick

This is an interesting ask, to make sure we deliver it the correct way, I want to get your thoughts on couple things --

1. AWSMobileClientError currently has error messages which are targeted to developer and sometimes the end user. How do you intend on making sure the end-use does not see the messages targeted for developer?
2. Using the switch / else if of AWSMobileClientError, you can easily have a list of error types whose messages you can propagate. Wouldn't that be a better approach to make sure no messages that are intended for developer reaches the end user?

Best,
Rohan

[Czajnikowski]

As every case has it's associated message we can also take this approach:

public struct AWSMobileClientError: Error {
    public let type: AWSMobileClientErrorType
    public let message: String
}

public enum AWSMobileClientErrorType {
    case aliasExists
    case codeDeliveryFailure
    ...
}

Or just add a var message :

public enum AWSMobileClientError : Error {
    case aliasExists(message: String)
    case codeDeliveryFailure(message: String)
    ....
    var message: String {
        switch self {
            case let aliasExists(message: message):
                return message
            ....
        }
    }

This will still make selective reporting to the user possible.

[bernikovich]

Wouldn't that be a better approach to make sure no messages that are intended for developer reach the end user?

So you're saying that we should never use these messages in UI. But what error should we display to a user when he can't log in.

[palpatim]

We generally avoid propagating errors intended for the end user (although as @rohandubal noted there are some legacy exceptions). This should be something that falls squarely in the app domain. That way the app can handle localization of messages, aggregation of detailed error cases into simple user message, etc. @Czajnikowski's approach would be a good start, with the addition of localization using your app's localized resources.

That said...

While we would not recommend these as user-facing strings, but this would still be a useful addition even for debugging and internal reporting. I'll look at getting #1270 pulled in.

[palpatim]

We released this in 2.10.0. Please let us know if you have any issues.

[stale]

This issue has been automatically closed because of inactivity. Please open a new issue if are still encountering problems.