Type comparison with UnderlyingExceptions might not be working as expected.

[jmartins-sh]

Description

Hello there! I'm currently testing scenarios where Cognito triggers (Lambdas) might return validation errors. While catching the LambdaException, I noticed that the underlying exception has a prefix of "_$".

For example, I encountered _$UserLambdaValidationException, whereas the exception provided by amplify-flutter is simply UserLambdaValidationException (without the "_$").

Is this expected behavior? Did I misunderstand something?

Appreciate the help. :)

Categories

• Analytics
• API (REST)
• API (GraphQL)
• Auth
• Authenticator
• DataStore
• Notifications (Push)
• Storage

Steps to Reproduce

1. Create a lambda that throws an Error("Not authorized to use the system.");
2. Catch the exception in flutter code
3. Compare the type of underlying exception (supposed to be the _$UserLambdaValidationException) inside the LambdaException with UserLambdaValidationException
4. The comparison returns false.

Screenshots

Platforms

• iOS
• Android
• Web
• macOS
• Windows
• Linux

Flutter Version

3.19.1

Amplify Flutter Version

1.7.0

Deployment Method

Amplify CLI

Schema

No response

[Jordan-Nelson]

Hello @joaoantoniomartinsfilho

_$UserLambdaValidationException extends UserLambdaValidationException. Here is the class definition. It is an internal class used for json serialization with built_value.

If you want to check if the exception is a UserLambdaValidationException you can do the following.

if (e is UserLambdaValidationException) {
  // handle exception 
}

Let me know if you have any other questions.

[jmartins-sh]

Hey @Jordan-Nelson, how's it going?

Thanks for the reply.

Do you mean checking directly the underlying exception, instead of the runtime type?

[jmartins-sh]

Hey @Jordan-Nelson , I followed your suggestion, but even after that, the comparison using the is operator with underlyingException is returning false, as you can check in the screenshot below.

Did I misunderstand something, or is there something else I need to consider?

[Jordan-Nelson]

@joaoantoniomartinsfilho You are not missing anything. That looks like unexpected behavior. We will see if we can reproduce it.

[Jordan-Nelson]

Hello @joaoantoniomartinsfilho - This does appear to be a bug. The exception is not getting mapped correctly. e should be type UserLambdaValidationException, not LambdaException.

The reason that you are not able to type check the underlying exception is that there are actually two UserLambdaValidationException types. One is public and extends AmplifyException. The other is private and is only intended to be used internally. The underlying exception is the private/internal one. However, if e was the correct type you would not need to check the type of e.underlyingException

Thanks for raising the issue. I will look into a fix and let you know when we have an update.

[Jordan-Nelson]

@jmartins-sh - This issue was addressed in Amplify Flutter v2 which was released a couple weeks ago. There were some breaking changes in this version. Please see the upgrade guide for more info.

[jmartins-sh]

Hey @Jordan-Nelson, thanks for the reply.

I just have one more question, is the lib amplify-flutter independent of Amplify Gen 2 right? Or Am I getting this wrong? My project is currently running in Amplify Gen 1 (amplify-cli and cloud). Will we face any issues using the lib 2.0?

Appreciate it.

[Jordan-Nelson]

Hi @jmartins-sh - Amplify Flutter v2 is compatible with Amplify Gen 1 and Amplify Gen 2.