Error handling: distinguishing among different error codes is difficult when evaluating a PlatformException

[uwieske]

When a PlatformException is thrown, it is very difficult to accurately extract the error code from the message property of PlatformException. Therefore, writing an error handling logic to determine the error code, is very error prone. It is essential to distinguish between error codes in order to give better user experience on screen level. Example: If a user cancels an authentication (login) procedure, I would like to display a snackbar with a cancel message text.

My observation is based on iOS device,as I have been testing for iOS first. But the same observation should be applicable for Android device.

[MaikuB]

This may not be possible or time consuming to do that someone else in the community will need to help with this. This is because the plugin is a wrapper for Android and iOS SDKs, each of which have their own way of dealing with various errors and likely don't use the same error code on both platforms. For the specific scenario you mention, from what I remember, it was possible to look at the message in the exception to see if cancelled was mentioned

[uwieske]

I understand with respect to the timeline and nature of the problem. As to your suggestion, such an approach is error prone and makes an error handler hard to implement. The text of the message property does not follow a strict/discrete pattern for parsing and extracting words that indicate the cause of an error. I'll give it a shot and will fork from the repository (a pull request) .

[MaikuB]

To clarify what I meant in case it wasn't clear and note that as I say this that I agree that use of error codes is better approach but I wasn't referring to complicated pattern matching but to see if the message string contains the word(s) "cancelled" or "user cancelled. This is just for the cancel scenario and should be sufficient in the absence of error codes as those SDKs have been around for years now without changes around there. For what's it worth, from what I remember when I looked at one of the Auth0's SDKs a while back, the code took a similar approach to look for certain words to figure out if a token had expired

[uwieske]

I got you.

[MaikuB]

Closing this as it's been many months with no further updates. Anyone interested in this case submit a PR and I'll review it