Classes used to manage exception

Question

Is it good to have a class with short methods used to catch Exceptions?

class ContractUtils{
  public static String getCode(Contract contract) throws MyException{
    try{
      return contract.getInfo().getCode(); //throws ContractException and LogicException
    }catch(Exception e){
      throw new MyException("error during code reading:"+e.getMessage, e);
    }
  }
  //other methods like above...
}

Ehhhh. Exceptions should be handled as soon as you can usefully respond to them. Generally that doesn't tend to be in some random utility method, but either lower down (in `contract.getInfo().getCode()` itself) or higher (at the application level where you can produce a useful error message). — Louis Wasserman, Oct 15 '15 at 18:26
What if `contract.getInfo().getCode()` throws e.g. a `NullPointerException` or an `ArithmeticException`? Surely in these situations you wouldn't want to catch and throw a `MyException` instead? — Paul Boddington, Oct 15 '15 at 18:28
Nope, just put your try/catch directly in your real method (where you have a contact and want to get it's code). Better surround "contract.getCode()" with a try/catch than using you "getCode(Contract contract)" static method. — Fundhor, Oct 15 '15 at 18:31
The use case scenario is this one: I'm working with Contract class gived me from external actors, these class throw two types of Custom Exception for every get method, my idea was to have a class to manage these Exception and put a useful error message inside a new custom exception. at the higher level i will catch every exception and log the message with this patter: "Error during contract edit: "+e.getMessage. So the result i would expect is like this: "Error during contract edit: error during code reading: value is null" — raythurnevoid, Oct 15 '15 at 18:35
`contract.getInfo().getCode()` is called multiple times, i don't think it is good to repeat the same try/catch block several times. — raythurnevoid, Oct 15 '15 at 18:48

score 3 · Answer 1 · edited May 23 '17 at 12:10

3

If a custom exception provides additional context or value to the calling code, then it's useful and encouraged to create them.

You're approach to using static methods is totally acceptable. Here's a good SO answer defining use cases for short static methods.

edited May 23 '17 at 12:10

Community

1
1

answered Oct 15 '15 at 18:36

Keith

3,079
2
17
26

score 2 · Accepted Answer · answered Oct 15 '15 at 18:37

2

Your utility class ContractUtil introduces a level of indirection just to translate the original exception into another exception:

Instead of the direct call:

 return contract.getInfo().getCode()

you are now writing the more artificial

 return ContractUtils.getCode(contract);

But there might be situations where this solution can be justified, e.g.:

You are not allowed to throw ContractException or LogicException, and you are calling this method a lot of times.

But if you can change its signature it would e better to redesign the original method to throw only MyException.

answered Oct 15 '15 at 18:37

wero

32,544
3
59
84

it's not called very often but i have to use it multiple times so i thought to use a single method to manage the exception one time and always get the same message error – raythurnevoid Oct 15 '15 at 18:45
1

@user1951947 then wouldn't it be better to move this error message normalization into the method? And as I said if this is not an option then your solution seems ok to me. – wero Oct 15 '15 at 18:49

score 1 · Answer 3 · answered Oct 15 '15 at 18:50

1

It can be useful to separate application logic from error handling for readability.

But not in utility class because you can forget to use it, and accomplish its task directly and still expect a custom exception. I would place this logic in Contact class if it is used often enough (and make Contract.getInfo() private). Another downside is, that it can lead to utility classes being too knowledgeable(LoD - https://en.wikipedia.org/wiki/Law_of_Demeter) about implementation details of other classes, possibly breaking encapsulation and making them less maintainable because of higher dependence.

And, you may want to catch specific exceptions.

answered Oct 15 '15 at 18:50

Uber Bot

511
3
8

Yeah, i agree with you that this thing should be done into the Contract class, unfortunately it become as it is from an external actor and the option to alter it is not possible, then i decided to write a sort of "proxy" for the Contract class. – raythurnevoid Oct 15 '15 at 18:58
1

I see, you can wrap it using composition, if it isn't too big. – Uber Bot Oct 15 '15 at 19:02
Yes it could be a good solution also to wrap it and override the methods i have to call, i like it. – raythurnevoid Oct 15 '15 at 19:12

score 0 · Answer 4 · edited Apr 12 '17 at 07:31

0

It is always better to catch and handle exceptions separately in your code. Assigning a common custom exception is not recommended.

Refer this link for best practices in managing exception:

https://softwareengineering.stackexchange.com/questions/209693/best-practices-to-create-error-codes-pattern-for-an-enterprise-project-in-c

edited Apr 12 '17 at 07:31

Community

1
1

answered Oct 15 '15 at 18:34

Prem

157
7

The OP never stated to what extent those exceptions were being managed. Virtually every COTS and OSS library creates custom exceptions. Also, you linked to an answer that was found to be too broad by the SO user community. – Keith Oct 15 '15 at 18:42

Classes used to manage exception

4 Answers4