org.sonar.l10n.java.rules.squid.S2221.html Maven / Gradle / Ivy

Go to download

Show more of this group Show more artifacts with this name
Show all versions of java-checks Show documentation

There is a newer version: 8.6.0.37351


  Catching Exception seems like an efficient way to handle multiple possible exceptions.
  Unfortunately, it traps all exception types and so both checked and runtime exceptions, casting too broad a net.
  Indeed, was it really the intention of developers to also catch runtime exceptions? To prevent any misunderstanding,
  if both checked and runtime exceptions are really expected to be caught, they should be explicitly listed in the catch clause.


Noncompliant Code Example
try {
  // do something that might throw an UnsupportedDataTypeException or UnsupportedEncodingException
} catch (Exception e) { // Noncompliant
  // log exception ...
}


Compliant Solution
try {
  // do something
} catch (UnsupportedEncodingException|UnsupportedDataTypeException|RuntimeException e) {
  // log exception ...
}

or if runtime exceptions should not be caught:
try {
  // do something
} catch (UnsupportedEncodingException|UnsupportedDataTypeException e) {
  // log exception ...
}


Exceptions
No issue is raised if a method in the try block explicitly throws an Exception.

See

  MITRE, CWE-396 - Declaration of Catch for Generic Exception