國外大佬給出的三種處理異常的套路!
作者：Radek Hecl
原文鏈接：
https://dzone.com/articles/good-exception-handling
Oh no, don't do this to me...
譯文：
哦，請不要這樣寫……
// 寫一句注釋跳過異常
try {
throw new IOException("Made up");
} catch (IOException e) {
// 跳過
}
// 記到日志里，繼續(xù)處理
try {
throw new IOException("Made up");
} catch (IOException e) {
log.error("blah blah blah", e);
}
// 標(biāo)記 TODO，不做任何處理
try {
throw new IOException("Made up");
} catch (IOException e) {
// TODO - 處理異常 (;
}
.... and still, I am finding those catch blocks inside various projects. This is a great way to suppress the problem — for a short period of time. A few weeks or months later, this will become a nightmare for developers. Walking through the old log files and trying to figure out what went wrong is definitely not that most people want to do. Therefore, let's avoid that.
The first rule is that catch blocks are here to handle exceptional situations. Logging exceptions and moving on is not considered as handling. The only case when it makes sense to suppress exception is during the closing of the resource after a prior exception (this case isn't covered within this article; if you are interested, then here is an old yet still very good blog post written by McDowell).
There are three basic patterns of how to handle exceptions: translate, retry, and recover.
Translate is often used when you have to deal with a checked exception, your method can't bubble it up, and recovery is not possible. In such cases, it is appropriate to translate it into a runtime exception and throw up. Then, the runtime exception is typically handled in the framework level. Retry is useful when dealing with unreliable services. It makes sense only if retrying makes sense fundamentally. The good example is retrying to overcome network interruptions. Recover is good when the strategy for doing that is defined. For example, you can write data to the local storage if sending over network fails. Of course, then it's necessary to define what to do with that file.
In addition, the mentioned patterns might be combined. Examples are as follows.
譯文：
我在各種項目中發(fā)現(xiàn)了這種 catch 語句。這是一種“好辦法”，可以在短期內(nèi)掩蓋問題。然而幾周或幾個月后，這些代碼將成為開發(fā)人員的噩夢。絕大多數(shù)人可不想讀日志查問題。因此，還是讓我們避免這種情況。
規(guī)則一：catch 語句是用來處理異常的，把異常記到日志里然后繼續(xù)執(zhí)行不算處理。唯一的例外是，在發(fā)生異常后關(guān)閉資源（本文不討論這種情況；如果感興趣，可以參考這篇 McDowell 的博客，雖然寫的時間比較早，但內(nèi)容很不錯)。
有三種處理異常的基本模式：轉(zhuǎn)換（translate）、重試（retry）和恢復(fù)（recover）。
轉(zhuǎn)換經(jīng)常用于處理受檢異常（checked exception），在方法中異常無法拋出，并且無法恢復(fù)時使用。在這種情況下，將其轉(zhuǎn)換為運行時異常（runtime exception）而后拋出是最合適的做法。接下來，運行時異常通常由框架處理。在處理不可靠的服務(wù)時，重試非常有用，前提是重新嘗試有意義。一個很好的例子就是網(wǎng)絡(luò)中斷重試。如果定義了這種策略，那么就能夠恢復(fù)到正常狀態(tài)。例如，如果通過網(wǎng)絡(luò)發(fā)送數(shù)據(jù)失敗，可以將數(shù)據(jù)寫入本地存儲。當(dāng)然，這時就必須定義如何處理該文件。
此外，上面提到的模式可以組合，比如像下面這個例子如下。
// 轉(zhuǎn)換
try {
throw new IOException("Made up");
} catch (IOException e) {
throw new RuntimeException(e);
}
// 重試5次后放棄
boolean end = false;
int count = 0;
while (end == false) {
try {
// 發(fā)送信息
if (true) {
throw new MessagingException("Made up");
}
end = true;
} catch (MessagingException e) {
if (count >= 5) {
// 嘗試5次放棄。
throw new RuntimeException("was not able to send message even after five tries", e);
}
++count;
try {
Thread.sleep(30000);
} catch (InterruptedException e1) {
Thread.currentThread().interrupt();
throw new RuntimeException(e1);
}
}
}
// 恢復(fù)：如果傳輸失敗記錄到文件
try {
// 發(fā)送信息
throw new MessagingException("Made up");
} catch (MessagingException e) {
try {
// 寫文件
throw new IOException("Made up");
} catch (IOException e1) {
// 如果寫文件失敗，不再進(jìn)行恢復(fù)
throw new RuntimeException(e1);
}
}
If everything fails, then this way will at least guarantee that you will be aware of the problem. In addition, it will provide you always the true cause of the issue; therefore, you will be able to quickly identify where the problem is!
Happy handling!
譯文：
如果一切都失敗了，那么上面這種方法至少可以確保你能意識到問題所在。此外，它還提供了問題的真正原因，從而讓你能快速定位問題。
祝編程快樂！
推薦閱讀：
喜歡我可以給我設(shè)為星標(biāo)哦
好文章，我?在看?
