You need to sign in to do that
Don't have an account?
TehNrd
Try-Catch Code Coverage question
Our triggers add great new functionality but as of now none are system critial. So for each trigger I have try/catch statements that catch standard exceptions and adds it to a custom built exception log I've created. http://community.salesforce.com/sforce/board/message?board.id=apex&message.id=978\
The problem I've run into is covering the catch code with test coverage. It seems like a Catch 22. If my test throws an exception it fails, but I somehow need it to throw an exception to cover the catch statement. Even with the catch code not covered we still have 90% code coverage but I'd like to cover as much as possible.
-Thanks
Jason
The problem I've run into is covering the catch code with test coverage. It seems like a Catch 22. If my test throws an exception it fails, but I somehow need it to throw an exception to cover the catch statement. Even with the catch code not covered we still have 90% code coverage but I'd like to cover as much as possible.
-Thanks
Jason
try{ //some code //Exception Testing and Handling--------------------------------- if(utility.throwExceptionError() == true){ string e = null; e.tolowercase(); } }catch(Exception e){ //Catch code }
In a utility class I have a static boolean that I set to true when testing so that a null pointer exception error occurs and then I can test the catch block of code.
Using this testing example as a template worked for me and covered my try catch code block.
Testing Example
I've been using this method to cover the try-catch statemtents in our test coverage, but now we run into the problem that custom validation rules on related objects aren't firing when the trigger inserts them (i.e. firing a trigger to create a related [custom_object__c] record every time an Account checkbox is checked on insert).
For a weird example, say you want to allow users to create Accounts and also create records of a custom object (related to the Account) called "Non_Swear_Word__c".
You allow swear words to be entered into a text field on the account, but you won't allow swear words to be entered into the corresponding field on the Non_Swear_Word__c object.
You create a validation rule on the Non_Swear_Word__c object to keep the user from entering any of the swear words that come to mind (these will flow easily once you arrive at paradox of what we're trying to accomplish).
Next you create a trigger on the account that automatically creates a Non_Swear_Word__c record once an account is inserted with a checkbox checked. The trigger would transfer this "Dev_Thoughts" textfield value over from the account to the Dev_Thoughts__c field on the new Non_Swear_Word__c record. If the value of Dev_Thoughts__c is one of the swear words in your validation rule, it's going to throw an ugly validation error if there's no try-catch. If there is a try-catch that merely asserts and debugs, it will allow the box to be checked on the account, but will error in the background (you won't see an error) and the trigger WILL NOT create a Non_Swear_Word__c record like it's supposed to when the box has been checked. You may not even notice that it didn't create it. This is a problem. Here's an example of what I'm talking about (the checkbox field will be called "Not_using_swears__c"):
If there's a swear word in the Dev_Thoughts__c field, this will blow up with a huge red error on the Account edit page and will not let you save it until you remove the swear. It works, but it's ugly and hard to read. Also, it will send the developer an email every time somebody hits that unhandled exception error.
This will prevent an email from going to the developer and it will allow the Account record to be inserted, and will be 100% covered in the test coverage (not shown), but it WILL NOT create the related Non_Swear_Word__c record.
This is the paradox. You'll have to either put a validation rule on the account that prevents the user from entering swears when they've checked the "Not using swears" checkbox (in this case the most logical). Option 2 would be to force the error onto the screen like this:
While this would be 100% coverable under test coverage (not shown), it will also throw an error message every time the user tried to insert an Account. This can be prevented by removing:
What this means is that you'll have 1 line of code not coverable by test coverage.
If you REALLY want to cover this line of code, you'll have to create a compromise workaround to allow most of all 3 to happen. The following will allow the Account record to be inserted and allow the Non_Swear_Word__c record to be inserted by editing the offensively vulgar language in the Dev_Thoughts__c field before inserting the Non_Swear_Word__c record:
Only problem is that you'll have to make sure that any and all validation rules on the Non_Swear_Word__c object are handled in your Account trigger...otherwise the new Non_Swear_Word__c record won't be created from the Account Trigger.
I just had a new discovery (for myself at least). if you put your try-catch all on the same line then it appears that it doesn't need to error out in order to cover that catch...it covers the line with the "try" part. For example:
I found that you can retain the structure, but just don't have the catch on a new line.
Excellent - that worked for me.