Created
April 1, 2018 22:03
-
-
Save bill350/830f0ecbfd9e847db5ef2d473c6a95c7 to your computer and use it in GitHub Desktop.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| extension Error { | |
| var localizedMessage: String { | |
| if let error = self as? SignIn.Error { return error.underlying?.localizedMessage ?? error.localizedMessage } | |
| if let error = self as? Network.Error { return error.localizedMessage } | |
| if let error = self as? Store.Error { return error.localizedMessage } | |
| return L10n.commonErrorMessage // Fallback error message | |
| } | |
| var underlying: Swift.Error? { | |
| if let error = self as? SignIn.Error { return error.underlying } | |
| if let error = self as? Network.Error { return error.underlying } | |
| return nil | |
| } | |
| } |
Author
Hi Eduard, thank you for your feedback!
Yes, I agree with you, we can improve the code below.
For the Medium post & to be sure by reading the code that we manage all potential subcases, we've put all cases separately.
The opposite is good too, as you expose, by generalize the behavior and specify it after.
That makes sense ;)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I think this could be improved by casting errors to Underlying or Localizable like this:
This way you can just add new errors and they will work out of the box.
What do you think?
If you want to override a particular error case, you can just add it.