2

This is a result of my previous question Lightning component action responds with internal server error which I was finaly able to troubleshoot and resolve on my own.

My original issue was that my apex controller method expected an integer but the JSON was deserializing as a string. This is actually not a problem as I'm using the number in a string anyway so it actually cleans up the code a bit.

Or so I thought...

After fixing that Issue I began getting "illegal argument" errors in the apex logs. The line of code that it was pointing to was:

resultSize = String.escapeSingleQuotes(resultSize);

Which I added since it was a string param and I was using it in a dynamic query. The question is, if JSON deserialized it as a String into a String param, why would this cause an illegal argument error when trying to use it as a String?

I was able to resolve the error by the following:

resultSize = String.escapeSingleQuotes(String.valueOf(resultSize));

but the question remains, why does it seem SF is having such a hard time serializing an integer correctly and what is the best pattern to use to reduce these errors?

2 Answers 2

0

My component attribute was defined as an integer:

<aura:attribute name="ResultSize" type="String" default="5"
                description="The number of results that will be displayed"/>

My controller was getting the value from this parameter:

var resultSize = component.get('v.ResultSize');

And then adding it to the params object:

var params = {
    "searchText" : searchString, 
    "SObjectType" : SObjectType, 
    "comparefield" : comparefield, 
    "resultSize" : resultSize
};

Then passing this object to the action:

action.setParams(params);

My apex method signature however, was expecting a string (a by product of the solution to my previous question) since sfdc was not able to properly deserialize the integer.

public static List<String> getSearchSuggestions(
    String searchText, String SObjectType, String comparefield, String resultSize
)

My best guess is that the deserialization from an integer to a string carried over some hidden properties that identified the variable as not a string which caused the "illegal argument" error.

Defining my parameter as a String allows it to be deserialized as a string and allows me to get rid the extra string.valueOf(resultSize).

Since we know we can't deserialize an integer into an integer (from my previous question) and we can't deserialize an integer into a string (this issue) it may be best to keep all properties as strings and handle type conversions in apex as needed.

Note: I have not tested with doubles (yet).

0

No need to write this much here, just do it:

Send the value as Integer to Apex from JS, and just cast it using

resultSize = Integer.valueOf(resultSize);

And also in the component set type="Integer"

In-depth detail available here on Lightning Components & AuraEnabled method parameters: What’s working and what’s not

2
  • I'm using it as a string anyway so it would be string.valueof(integer.valueof(resultsize)), which is just excessive, doing it as a string all the way works just as well. If I needed it as an integer then integer.valueof(string) also works. If I have to do conversions in apex code, I'm going to do it consistently. Even in the article you linked, treating the attributes as strings solves most of those issues and the author even admits to converting classes to strings himself and handling conversions on the controller. The answer I posted is the best solution.
    – gNerb
    Mar 28, 2018 at 20:51
  • I guess you are using this value in the SOQL offset then if you take it as Integer that would be easy for you to do calculations(if you are doing any). Mar 29, 2018 at 3:46

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .