2

I have a simple apex method that is used by an Aura Lightning component:

@AuraEnabled
public static void doSomething(String requestInfo) {

    MyRequest request;
    try {
        request = (MyRequest) JSON.deserialize(requestInfo, MyRequest.class);
    } catch (Exception ex) {
        System.debug(LoggingLevel.ERROR, ex + ' - ' + ex.getCause() + ' - ' + ex.getStackTraceString());
        throw new AuraHandledException(ex.getMessage());
    }

    // Do something ...
}

So my question is do I need that try/catch block at all?

Initially I thought that it might be useful because if requestInfo is null or not of the type MyRequest, JSON.deserialize()will throw exception, and the lightning component will see the "Script-throw error", not the actual error message. This is because the lightning framework "hides" unhanded errors.

Now I realized that this is redundant because of the following reasons:

  1. Normally exceptions cannot happen in JSON.deserialize(requestInfo, MyRequest.class); because what comes in requestInfo is basically defined by developer in the lightning js controller. One exception to this might be the case when requestInfo is generated dynamically in lightning js controller. This is very rare case, however. And in any case it should be tested.
  2. If someone smart attempts to use doSomething with inalid arguments directly from DevTools or curl, they will get a "Script-throw error" error. This is fine because this functionality was not intended to be used in that way.

So what I ended up was:

@AuraEnabled
public static void doSomething(String requestInfo) {
    if (String.isBlank(requestInfo)) {
        throw new AuraHandledException('requestInfo cannot be blank');
    }
    
    MyRequest request = (MyRequest) JSON.deserialize(requestInfo, MyRequest.class);

    // Do something ...
}

I check if requestInfo is blank (null or '') and throw an error in case it is. Again this is for developers who will use this method. During development, instead of getting null pointer exceptions they will get a meaningful error message. Ideally, end users will never see this error.

I understand that this question may be too broad or opinion-based, but I think it may be useful to developers by providing guidance on this kind of problems.

2

You should definitely be doing input validation, to the extent that a program must not run to completion on invalid data. It's also nice to give users a nice error when they screw up make a mistake. I agree that a properly written component shouldn't ever pass in invalid JSON, so I wouldn't handle that exception. I also wouldn't handle the null/empty parameter condition, either. If I get an exception, I should easily be able to narrow it down in the developer console.

Of course, if you're an ISV, you may want to catch and log all errors, because logs are otherwise hard to obtain, but for "casual" development, it's okay to cut corners that people aren't supposed to know exist and that will still crash properly. Some will argue that you should always handle those exceptions, and there's nothing wrong with overkill, but it's really not necessary. If the program does not run to completion because the user was trying to "hack the system", they shouldn't need to know or care what happens behind the scenes. That's what the Apex Exception emails and Debug Logs are for.

The only errors you should handle and properly report are those errors where the user could genuinely enter in a value that needs to be addressed by the user (e.g. they put in a negative number or something), although I would prefer such validations be handled on the client-side as much as possible. You do need to verify boundaries (e.g. negative numbers) such that your code can't run to completion on invalid data.

For example, if it was a banking app, putting in a negative withdrawal amount should not add money to their account (subtracting negative numbers is addition). The user should be told they can't do this on the client side, and an exception should happen on the server side (it could be a generic exception so people trying to hack the system can't tell why it failed).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.