[SalesForce] String Exception is not being caught

Some how nothing is being caught. Not sure, but it could be not understanding how exception really works.
So I have a method that does everything including querying, than finally does an update to an opportunity record

public void createAlert(){
    try{
        for (List<OpportunityLineItem> oliList : [Select oli.id from OpportunityLineItem oli Where oli.OpportunityId = :oppId]){

        //some logic
        }   
        //some logic
        update updateOpp;
    } catch (System.StringException e) {
        system.debug('Exception===>' + e.getMessage());
    }                                                   
}

I am invoking this method from the develop console right now like this :

Alert opp = new Alert('aaaaaaaaa');
opp.createAlert();

I get this error:

11:36:07:147 FATAL_ERROR System.StringException: Invalid id: aaaaaaaaa

But it never caught the exception, so I never got the "Exception===>" debug message.

Best Answer

It's a little lazy, but instead of catching specifically the StringException, you could just catch Exception, which is a catch-all bucket:

} catch (Exception e) {
    system.debug('Exception===>' + e.getMessage());
}

Is that sufficient for your needs?

Also, your constructor is expecting an Id - and you are not passing in a valid Id. Salesforce does check Ids for legitimate formats. Pass in something that will pass the test, such as 005000000000000000.

Related Solutions

[SalesForce] throw an exception in apex and still log the caught exception

First please take a look at this answer for a partial solution / approach, Can I prevent an insert to be rolled back even if my class (later) runs into an exception?.

Basically as per the Apex Developers guide the final commit transaction management is baked into Apex, meaning it will always rollback if you let the platform handle your exceptions, if you don't you have to manage the rollback scope yourself or accept any DML that has been issued be committed.

If the entire request completes successfully, all changes are committed to the database. For example, suppose a Visualforce page called an Apex controller, which in turn called an additional Apex class. Only when all the Apex code has finished running and the Visualforce page has finished running, are the changes committed to the database. If the request does not complete successfully, all database changes are rolled back

The only way to get control of this is to use the try/catch/finally semantics, along with Savepoints, and critically not throwing any exception (note that as per the answer above some system exceptions cannot be caught sadly). Since your implementing the Auth.RegistrationHandler interface your stuck with its method signature and thus cannot code any alternative way to pass errors back, not does there appear to be any support for this on the interface itself.

Passing a null user back from createUser. What happens if you using try/catch/finally with a logging approach as above and then null back? I expect the system will handle this and present some general error message. Of course in this case your more detail errors will have been logged, since technically the call completed successfully. You would of course have to educate your users / admins to check your own log in this case. Given the frequency of the issues, perhaps this is tolerable? As regards the updateUser method, i don't see any way to infer errors with a successful execution of the method.

Summary and System.debug? Sorry this is not the answer you wanted, but i believe this is the situation. Your not the first to want to implement such a logging approach as you can see. Ultimately its a matter of how far your prepared to go against the transaction management semantics of the platform vs resorting to having your Admins enable Debug Logs and adding System.debug output to your code to output messages to the standard platform log that can then be reviewed for your errors.

[SalesForce] Assertion failure that a null pointer exception is caught

Exceptions have a type (e.g. "NullPointerException") and a message (e.g. "Argument cannot be null") and perhaps most usefully of all a stack trace (the line number and class name that the exception was thrown from and the calling line numbers and class names). If you are going to add error handling logic for random programming errors then I recommend that you capture all 3 pieces of information as otherwise you are making the process of finding and fixing the error harder than it needs to be.

See the Common Exception Methods that are available.

It is often be better to not add logic that tries to handle programming errors. For example, in a Visualforce controller class the default error handling works well and the stack trace detail can be obtained by turning on "Development Mode" for a User and reproducing the error using that User.

Running this using "Execute Anonymous":

try {
    Date.valueOf((String) null);
} catch (Exception e) {
    System.debug('>>> ' + e.getMessage());
}

confirms that the error message string will only contain "Argument cannot be null" (though FYI the exception thrown is of type "NullPointerException").

Best Answer

Related Solutions

[SalesForce] throw an exception in apex and still log the caught exception

[SalesForce] Assertion failure that a null pointer exception is caught

Related Topic