Is there a limit on the number of exceptions I should throw from a method?

Question

this is my function declaration

public init(){
    try{
         initApplication();
     }catch(A1Exception){

     }catch(A2Exception){

     ...
     }catch(A5Exception){

     }
}

private void initApplication() throws A1Exception, A2Exception, A3Exception, A4Exception, A5Exception {
   initApp1(); //throws A1, A2, A3
   initApp2(); //throws A4, A5
}

Q1. Will this have performance impact?

Q2. Do you see smell in initApplication() ?

Answer 1

Q1. Will this have performance impact?

• No, not if they are 'genuine' exceptions (i.e. not being used for normal program control flow)

Q2. Do you see smell in initApplication()?

• No, not if initApplication() can be expected to raise N exceptions, i.e. if there are N - exceptional circumstances that could prevent initApplication() from completing it's work.

Answer 2

1: The performance impact will be minimal...

2: But it's not necessarily a good idea, as having excessive boiler plate code makes it hard to read. If every exception is going to be handled the same way, then you should either do a catch of the base class Exception. Or you can have initApplication() throw a custom exception -- something like ApplicationInitializationException, which conveys a little more meaning about what went wrong. You can set the message for the exception to be the exact details.

There are some cases where you might get 5 different exceptions, and might have to deal with all of them differently. In that case, catching all 5 would be the proper thing to do. But it's worth thinking about if that's really necessary before you implement it.

Answer 3

I don't see a problem throwing whatever Exception your code requires. My first impression when looking at the example is that Exceptions might be used here to control the flow of your application. Be careful not to do that. Exceptions should only be triggered in exceptional cases.

One reason why process flow should not be handled via Exceptions is that raising Exceptions is an expensive process. Though the structure of multiple catch blocks shouldnt result in a performance hit, the (potential) underlying process that uses Exceptions to control flow would not perform well.

With that in mind, is there a 'smell'? Only if the above concern is true in the design of the code.

Answer 4

Hi,

There is no limitation as to how many exceptions can be thrown by a method. The more exception you throw, the more you can be specific about any exceptions being caught.

Just I would like to point out a few suggestions which I follow. 1) Atleast have a generic exception at the last so if any other exception which may occur in your code is caught than being thrown to the calling class. 2) You can have category of Exception Classes like BusinessLogic Exception, InvalidDataException, SystemsException so you may have actually less no of exceptions being thrown from any method. (Unless your business demand exact exception 3) Always have error codes than throwing actual text messages which will make your application language independant.

Answer 5

In recent years there's been a feeling that checked exceptions are fairly harmful. Each of these exceptions, if they are checked, forces the calling methods to have to handle them or declare them. This breaks encapsulation, because now something of the lower level implementation details leaks up into the higher levels.

Joshus Bloch talks about this in Effective Java, which I highly recommend.

Answer 6

If there is no exception there is no performance impact, if an exception is thrown, there is some overhead finding the matching catch which will grow as you add more exceptions, but it should not matter, because exceptions should be er.. exceptional. The should not happen under ordinary circumstances.

In other words if you do not use throwing exceptions to control the flow of your program yuo should be ok, and if you do this is certainly a smell no matter how many catch clauses you have

Answer 7

On a purely technical note, the class file format introduces an upper limit of 65536 exceptions. The u2 type of exceptions_table_length is shorthand for an unsigned two byte quantity.

The Code attribute has the following format:

Code_attribute {
 u2 attribute_name_index;
 u4 attribute_length;
 u2 max_stack;
 u2 max_locals;
 u4 code_length;
 u1 code[code_length];
 u2 exception_table_length;
 {     u2 start_pc;
        u2 end_pc;
        u2  handler_pc;
        u2  catch_type;
 } exception_table[exception_table_length];
 u2 attributes_count;
 attribute_info attributes[attributes_count];
}

I only bring this up in case you are generating code. JSP developers often have to worry about problems with generated methods exceeding 64KB code size. This and other limitations are listed in Section 4.10 Limitations of the Java Virtual Machine.

Answer 8

I guess this answer is mostly related to the Q2 but view of it that is not so technical but might be worth considering anyway are the one behind the following two questions?

• Does it make sense for the user to catch all of them?
• Do you want to risk the user getting fed up with having lots of catch blocks and instead just insert a single "catch(Exception ex) {// ex.printStackTrace(); // enable this if we see problems}" or something similar and stupid.?

In this case I guess it might not be relevant but I think it is worth considering when doing API design in general.

Answer 9

Since nobody seemed to mention it:

I'd say if a method throws many different exceptions, it might do to many things. Especially many different things.

Answer 10

Do not throw any exceptions unless you are going to take an action if an exception is caught. Convert your checked exceptions to runtime exceptions for logging purposes.

More info on the topic can be found here