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
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 allowedthrow 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
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.
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 allowedmyMethod1(); }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 {/* ... */ }總結
以上是生活随笔為你收集整理的Java代码中常见技术债务处理之Exception的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: Junit4小技巧-测试基类
- 下一篇: 如何看待Scrum Sprint Bac