8

I am using SonarQube and it shows the following error:

Public methods should throw at most one checked exception.

// Noncompliant
public void delete() throws IOException, SQLException { /* ... */ }

// Compliant
public void delete() throws SomeApplicationLevelException { /* ... */ }

Does this means, SomeApplicationLevelException is a parent class and IOException and SQALException are derived from it? And we should throw the parent class exception? Thereby adhering to method throwing only 1 checked exception?

Because I have 2 exceptions that i have defined say for example Exception1 and Exception2 that extend Exception. And my method say, sampleMethod() throws them i.e,

public void sampleMethod() throws Exception1, Exception2 {
}

And the error is shown here. So should I have one class as parent (say MainException) and derive Exception1 and Exception2 from it and throw parent exception class? Like below:

public void sampleMethod() throws MainException {
}

Is the above solution proper?

slartidan
  • 20,403
  • 15
  • 83
  • 131
pgman
  • 493
  • 3
  • 12
  • 21
  • 1
    sounds like that is the solution to your case :D or you generate one dedicated exception for this method, which provides a little bit more information – Simon Schrottner Sep 18 '17 at 12:02
  • I have the same "Major" error SonarQube complaint with a couple of projects. After talking to a couple SME's at my office there are advocates and detractors for both schools of thought. My opinion is create a ``MainException`` parent class as you have stated, and make SonarQube happy. – Jeremy Sep 18 '17 at 13:42

2 Answers2

9

If you have a method in your application that is declared as throws SQLException, IOException, you are probably leaking internal implementation details to your method's users. Specifically, you're saying:

  1. Your method is implemented using JDBC and file I/O. Your users don't care how your method is implemented; they only care about what your method does.

  2. Your method, including any future version of it, will never throw any other checked exception. If in future you change your method so that it might throw another checked exception, it will break backwards compatibility.

The advice is to create your own application-specific class (derived from Exception), and only throw that in your method. You can, if you like, wrap the SQLException or the IOException (or any other exception) inside your application-specific exception as the cause.

Note, however, that there is a school of thought that says Java checked exceptions are a bad idea (and one of the reasons C#, and more modern languages such as Kotlin, don't have checked exceptions).

UPDATE: the above answer related to the first version of the question (edit #1). The question was subsequently updated to point out that the two thrown exceptions were application-defined ones, so therefore much of the above rationale no longer applies. The answer to the updated question is explained in this post.

Klitos Kyriacou
  • 10,634
  • 2
  • 38
  • 70
1

IOexception and sqlexception both are checked exception s,totally different from each other , now if we extend both from one exception and throw the parent exception , which is not a mandatory in java, it will be kind of misguiding the user of the api.

However, if you want to do it in ur app to avoid sonarqube error , you can catch all your specific exceptions and throw a custom exception wrapping the original exception information in exception message.

for example

try{

      ///piece of code that throws IOException and SQLException
}catch(IOException | SQLException ex){
   throw new DataException(ex,"Any customized message you want");
}

This DataException will then will be included in the throws clause of method signature having this try catch.

DataException extends Exception class and by passing ex in the contructor you are wrapping the original exception in custom exception with your original exception info preserved.

pndey
  • 71
  • 4
  • thanks for your Reply. can you give an example / pseudo Code of how to wrap them in custom based exception in catch block. Sorry since am new i did not understand completely – pgman Sep 19 '17 at 08:39
  • I have edited my answer to incooperate the example, hope its clear – pndey Sep 19 '17 at 09:12