3

Is it possible to have an empty catch block in Apex?

I have the following code for illustration.

COMPILES:

public with sharing class Demo_ApexCatchBLock {
    public Date SendmeData(String input) 
    {
        Date s;
        try
        {
             s = Date.parse(input);
        }
        catch(Exception e){//Empty Catch Block.}
        System.debug(s);
        return s;
    }
}

DOES NOT COMPILE:

public with sharing class Demo_ApexCatchBLock {
    public Date SendmeData(String input) 
    {
        Date s;
        try
        {
             s = Date.parse(input);
        }
        catch{//Empty Catch Block.}
        System.debug(s);
        return s;
    }
}
6

There are two reasons your code failed to compile:

  1. You did not specify a catch argument.
  2. You commented out your closing bracket.

Instead of:

catch{//Empty Catch Block.}

the ill advised but compilable version would be:

catch (Exception pokemon){/*Empty Catch Block.*/}

It sounds like you were asking about #1. The closest you can come is catching a generic Exception, though many developers find this approach unpalatable. You should really catch specific types where you can. However all standard and custom exceptions must extend that generic type, and will hence be caught. That's why it is sometimes derisively referred to as a "pokemon catch" as in "gotta catch em all".


In regards to #2, you can, but it's a bad idea.

It's the programming equivalent of putting black tape over an engine warning light.

  • The reason OP's code did not compile is because he did not pass an argument to catch. I believe OP is asking about the arguments passed to catch as opposed to a simple "empty catch block". – krigi Jul 19 '16 at 21:04
  • @DasUberDanger It's not the only reason. Just one reason. Adding a type alone will not resolve. – Adrian Larson Jul 19 '16 at 21:07
  • 1
    There's a plausible exception (so-to-speak) to this -- empty catch blocks in testmethods: try{somecodethatisexpectedtofail; system.assert(false,'shouldnt happen --underlying code should throw exception');} catch(TheExpectedException e){} catch(Exception ex) {System.assert(false,'wrong exception thrown');} – cropredy Jul 19 '16 at 21:28
  • I'm not a huge fan of that pattern either. I prefer to cache it and assertEquals(null, unexpectedException). – Adrian Larson Jul 19 '16 at 21:31
  • @DasUberDanger Yes, I am wondering if I need to pass a type to the catch. That is my definition of an empty catch block. Here is a simple c# (fiddle) [dotnetfiddle.net/Widget/uhpjzZ] – abhi Jul 19 '16 at 21:33
5

Not possible to do what you are trying to do, but let's be clear about terminology: an "empty catch block" is completely fine but that is not what you are asking about.

You are really asking "do I have to pass an argument to catch" and the answer is YES. Try/catch syntax requires that an exception be passed to catch as an argument. At a minimum, catching the generic exception will suffice as you have done with your first example (Exception e).

You could also get specific and handle different exceptions different ways e.g. DML exception, SObject exception, etc.

See the docs for detailed information regarding exception types: https://developer.salesforce.com/docs/atlas.en-us.apex_workbook.meta/apex_workbook/apex7_4.htm

I have to ask: what are you trying to accomplish? Why do you think you want to be able to do this?

  • 1
    I am trying to demonstrate the VB equivalent of On Error Resume Next I know this a very bad idea in production code, but for the purpose of learning, it is ok. I am aware of handling different exceptions and have implemented them in live code. – abhi Jul 19 '16 at 21:29
2

Catching Exception is actually catching an untyped object. One cannot construct an Exception, since it is an abstract type. Apex requires that any Exception extends Exception and ends with the name Exception. Your first example actually illustrates catching an unknown exception type, while the second is just bad syntax.

As an alternative, you can use finally instead:

try {
    possiblyBadThing1();
    possiblyBadThing2();
} finally {
    somethingAlwaysDone();
}

This construct guarantees that somethingAlwaysDone will always be called, even if an exception occurs.

However, this means the exception isn't handled and will still be thrown after all finally blocks finish (they may be nested). You'd use this as a last chance clean up phase, but if you fail to catch at all, your transaction will still abort.

Catch always requires a single parameter to work, but the generic Exception class is used to handle all errors without crashing your program.

0

You have to catch an error even if it is generic, if someone said just "Leave your catch empty" they meant just don't do anything with the error

https://developer.salesforce.com/page/An_Introduction_to_Exception_Handling

  • Can you quote the relevant excerpt from that document? This answer is a bit of a stub. – Adrian Larson Jul 20 '16 at 0:34

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.