0

Although I have >95% code coverage, however, I'd still like to get it to 100% and need some guidance with the following :)

How would you enter the Exception block below via Test Class? Passing an empty string to method1 probably won't work. Any other ideas that would force this to happen?

public class SomeClass {

public static void method1(List<String> strings) {
    List<SObject> sObjects = [Select Id, Name FROM SObject WHERE Id IN :strings];
    if (SObjects.size() > 0) {
        for (SObject sObj : sObjects) { 
            try {
                method2(sObj);
            } catch (Exception ex) { //Need to test this block
                System.debug('***EXCEPTION***');
                ex.getStackTraceString();
            }
        } 
    }
}

public static void method2(SObject sObj) {
    //Do something here
}}

Any help would be appreciated. Thanks!

0

Without knowing the contents of method2, I'd have to say...

You can't possibly throw an exception here. The catch block can't be entered, as there's nothing here that can cause an exception.

Also:

if (SObject.size() > 0) {

This is pointless, as iterating over an empty loop is legal, and a query will never return a null value. You don't need it.

You'd need to check method2 for any specific exceptions thrown and handle those, but as it stands, you can't get an exception here.

| improve this answer | |
  • Thanks for the tip, I've removed that portion. It's based on implementation of Skills Routing specific for my org. The method2 would be calling PendingServiceRouting. Here's what Salesforce says - help.salesforce.com/… – gutsyfella Feb 4 at 15:10
  • @gutsyfella It'd be hard to test, because that code can't strictly fail under ordinary circumstances. I'm not familiar with the skill-based routing system, but it looks like it would be pretty hard to force an exception. – sfdcfox Feb 4 at 15:33
0

Completely generic exception handlers that catch any exception and "handle" it with a System.debug() are virtually never a good solution. These handlers run the risk of corrupting the data in your database because you're quite literally suppressing the natural effect of an "exceptional" error situation: the rollback of the transaction.

The best solutions are either

  • Completely remove this exception handler.
  • Write specific exception handlers that catch the exceptions method2() is documented to throw and handle them by making sure that data integrity is maintained (by, for example, using a savepoint/rollback structure) and implementing logic to recover from the specific error that's been caught.

If the handler is made specific, the input or conditions required to force it to execute in test context should become clearer.

| improve this answer | |
  • Thanks for the pointers, David. This is an org specific implementation w.r.t to the Apex flow defined here - help.salesforce.com/… – gutsyfella Feb 4 at 23:10

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.