java中insteadof_Java代码中常见技术债务处理之Exception

写在前面

异常处理是代码中常见的处理，本文根据SonarQube在异常方面的规则和常见检查结果，选取说明了常见异常处理中的技术债务，提倡技术债务最少的编码方式。

Exception handlers should preserve the original exceptions

Either log or rethrow this exception.

When handling a caught exception, the original exception’s message and stack trace should be logged or passed forward.

NONCOMPLIANT CODE EXAMPLE

// Noncompliant - exception is lost

try { /* ... */ } catch (Exception e) { LOGGER.info("context"); }

// Noncompliant - exception is lost (only message is preserved)

try { /* ... */ } catch (Exception e) { LOGGER.info(e.getMessage()); }

// Noncompliant - exception is lost

try { /* ... */ } catch (Exception e) { throw new RuntimeException("context"); }

COMPLIANT SOLUTION

try { /* ... */ } catch (Exception e) { LOGGER.info(e); }

try { /* ... */ } catch (Exception e) { throw new RuntimeException(e); }

try {

/* ... */

} catch (RuntimeException e) {

doSomething();

throw e;

} catch (Exception e) {

// Conversion into unchecked exception is also allowed

throw new RuntimeException(e);

}

错误实例：

protected int analyzeJobStep1(String jobName) {

try {

notifyBHandler();

return analyzeJobStep2(jobName)

} catch (Exception e) {

logger.error(e.getMessage();

}

return 0;

}

解决实例：

protected int analyzeJobStep1(String jobName) {

int nRet=0;

try {

notifyBHandler();

nRet = analyzeJobStep2(jobName);

} catch (Exception e) {

logger.error("notifyBHandler trigger exception", e);

}

return nRet;

}

Don’t directly use Exception and RuntimeException

Sonarrule:Generic exceptions should never be thrown (squid:S00112)

Using such generic exceptions as Error, RuntimeException, Throwable, and Exception prevents calling methods from handling true, system-generated exceptions differently than application-generated errors.

Noncompliant Code Example

public void foo(String bar) throws Throwable { // Noncompliant

throw new RuntimeException("My Message"); // Noncompliant

}

Compliant Solution

public void foo(String bar) {

throw new MyOwnRuntimeException("My Message");

}

Another related rule: Generic exceptions should never be thrown

the below should be avoided.

@Override

public void myMethod() throws Exception {...}

Define and throw a dedicated exception instead of using a generic one.

Exceptions should not be thrown in finally blocks

try {

/* some work which end up throwing an exception */

throw new IllegalArgumentException();

} finally {

/* clean up */

throw new RuntimeException(); // Noncompliant; will mask the IllegalArgumentException

}

Compliant Solution

try {

/* some work which end up throwing an exception */

throw new IllegalArgumentException();

} finally {

/* clean up */ // Compliant

}

Checked exceptions should not be thrown

The purpose of checked exceptions is to ensure that errors will be dealt with, either by propagating them or by handling them, but some believe that checked exceptions negatively impact the readability of source code, by spreading this error handling/propagation logic everywhere.

This rule verifies that no method throws a new checked exception.

CODE EXAMPLE

public void myMethod1() throws CheckedException {

...

throw new CheckedException(message); // Noncompliant

...

throw new IllegalArgumentException(message); // Compliant; IllegalArgumentException is unchecked

}

Solution Example

public void myMethod2() throws CheckedException { // Compliant; propagation allowed

myMethod1();

}

Public methods should throw at most one checked exception

Using checked exceptions forces method callers to deal with errors, either by propagating them or by handling them. Throwing exceptions makes them fully part of the API of the method.

But to keep the complexity for callers reasonable, methods should not throw more than one kind of checked exception.

NONCOMPLIANT CODE EXAMPLE

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

/* ... */

}

COMPLIANT SOLUTION

public void delete() throws SomeApplicationLevelException {

/* ... */

}