0

I have 2 classes in my module where one of the class say Class A has methods which could throw InterruptedException, NoSuchElementException and another class say class B has methods which calls the method from class A. Could someone please guide me with what is a good practice to implement exception handling? Shall it be CASE 1 or CASE 2 or any other way to do so.

CASE 1 ::

Class A

methodA1 throws InterruptedException, NoSuchElementException {...} methodA2 throws InterruptedException, NoSuchElementException {...} . . . . methodA10 throws InterruptedException, NoSuchElementException {...} 

Class B

a = new A(); methodB1 { try{ a.methodA1(); a.methodA2(); } catch(InterruptedException){ //do something } catch(NoSuchElementException){ //do something else } } methodB2 { try{ a.methodA9(); a.methodA10(); } catch(InterruptedException){ //do something } catch(NoSuchElementException){ //do something else } } 

SCENARIO 2 ::

Class A

methodA1 { try{ //perform actions } catch(InterruptedException){ //do something } catch(NoSuchElementException){ //do something else } } . . . . methodA10 { try{ //perform actions } catch(InterruptedException){ //do something } catch(NoSuchElementException){ //do something else } } 

Class B

a = new A(); methodB1 { a.methodA1(); a.methodA2(); } methodB2 { a.methodA1(); a.methodA2(); } 
1
  • It depends upon whether it makes more sense from your code's perspective to handle these exceptions in class A or B. Do you want it to be part of the methods' interfaces that these problems can happen and the client needs to deal with them, or can you reasonably handle them internally leaving the client none-the-wiser? Commented Oct 26, 2015 at 8:13

3 Answers 3

2

It really depends on what you need to achieve.

The situation might be flexible enough to allow you to handle exceptions as they arise within the specific module. For instance, you have some process which queues elements, an exception is thrown and in your exception handling code, you simply try again. The caller knows that when the method is called, something will be added but does not require to be informed of when/how.

On the other hand, the situation might require that you inform the caller immediately should something happen. Taking the above example, maybe the caller would need to know if the queueing was successful or not so that they could direct the user accordingly.

There are also scenarios where bubbling up the exception, although recommended, needs to be done in such a way that internal exceptions are not divulged to the caller since it could expose the internal structure of the module, which could be a security risk.

Usually, what one does is that, where necessary, exceptions are wrapped within custom exceptions. And if any errors occur, the custom exceptions are used to bubble up the error. It will then be up to the caller to decide what to do if/when an error occurs.

Sign up to request clarification or add additional context in comments.

Comments

0

rethrowing or handling depends whether the caller can handle the exception reasonably.

E.g. if an UI triggers a calculation via a method chain, it might not be reasonable that somewhere in this chain the exception gets lost, as it would be of interest to present in the ui the exception to the user.

So it mostly depends on the context which scenario is preferable.

A rule of thumb is: However can handle the exception reasonably should do so

Comments

0

It depends on what you want to achieve by that and where you want to handle the exceptions. If you can handle the exception properly inside the methodA1() it'll be easier to use the method (no try-catch necessary around method calls)

If you can't handle the exception in the method itself (e.g. not enough information to handle the exception properly) and you can only handle it properly in methodB1 then you should use SCENARIO 2

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.