surface `ComposeMessageError` details to user

[tomholub]

Maybe ComposeMessageError should be updated to provide more human readable error description.

Originally posted by @ivan-ushakov in #581 (comment)

Could you please show a screenshot of what it shows now?

[ivan-ushakov]

[tomholub]

Oh, definitely. The Core method surely returns some sort of error message, that should be surfaced to the user.

[ivan-ushakov]

@tomholub How we should map CoreError enumeration to string? I mean we can not use String object associated with enumeration element because it is not user friendly. So we need to have some kind of mapping from engineer kind of error to user friendly error.

Currently we have following elements in CoreError:

case exception(String)
case notReady(String)
case format(String)
case keyMismatch(String)
case noMDC(String)
case badMDC(String)
case needPassphrase(String)
case wrongPassphrase(String)
case value(String)

Maybe we don't need to map them all.

[tomholub]

Except for exception, notReady and value, these are all decryption-only errors. The swift code here is not ideal, since we are mixing them together - eventually we'll improve that.

The above error is probably returned in JSON as something like {"error": {"message":"Error: message could not be encrypted because the public key is invalid","stack":"Error: ...\n..."}}

That should become the exception case above, and the message and stack should be put into the exception error struct.

Then for the modal in that screenshot, it should show the message on top, then two newlines, then the stack. It will be a bit ugly but it will make for easier debugging (when customer sends a screen shot), which is more important than user friendliness.

[ivan-ushakov]

Look like error is thrown in JavaScript code openpgp.js

throw new Error('No keys, passwords, or session key provided.');

This is the reason why we don't have error type and use CoreError.exception. Message looks like this:

------ js err -------\nCore composeEmail:\nError: Error encrypting message: No keys, passwords, or session key provided.\n@\nasyncFunctionResume@[native code]\nasyncFunctionResume@[native code]\npromiseReactionJob@[native code]\n------- end js err -----"

[tomholub]

Got it. In that case, a modal like:

Error: Error encrypting message: No keys, passwords, or session key provided.

@
asyncFunctionResume@[native code]
asyncFunctionResume@[native code]
promiseReactionJob@[native code]

should be shown to user. Then, if the message is different, a different modal should be shown. It's up to you how to do it code-wise, as long as it's generic.

[ivan-ushakov]

OK, what do you think about this:

enum CoreError: LocalizedError, Equatable {
    case exception(String)
    case notReady(String)
    case format(String)
    case keyMismatch(String)
    case noMDC(String)
    case badMDC(String)
    case needPassphrase(String)
    case wrongPassphrase(String)
    // wrong value passed into a function
    case value(String)
    
    init(coreError: CoreRes.Error) {
        switch coreError.error.type {
        case "format": self = .format(coreError.error.message)
        case "key_mismatch": self = .keyMismatch(coreError.error.message)
        case "no_mdc": self = .noMDC(coreError.error.message)
        case "bad_mdc": self = .badMDC(coreError.error.message)
        case "need_passphrase": self = .needPassphrase(coreError.error.message)
        case "wrong_passphrase": self = .wrongPassphrase(coreError.error.message)
        default: self = .exception(coreError.error.message + "\n" + (coreError.error.stack ?? "no stack"))
        }
    }

    var errorDescription: String? {
        switch self {
        case .exception(let message):
            return message
        case .notReady(let message):
            return message
        case .format(let message):
            return message
        case .keyMismatch(let message):
            return message
        case .noMDC(let message):
            return message
        case .badMDC(let message):
            return message
        case .needPassphrase(let message):
            return message
        case .wrongPassphrase(let message):
            return message
        case .value(let message):
            return message
        }
    }
}

We could define description for each enumeration element. For now I just return associated message.

[tomholub]

The errorDescription is a bit verbose. I suppose Swift doesn't let you define it in a more compact manner, without having to list them all?

In general, this is an implementation detail that's not very important to me. As long as it makes it easy to make error modals in all sorts of situations conveniently.