他們2個(gè)都是Throwable的子類。

error是程序沒有辦法處理的異常，常見的有OutOfMemoryError，StackOverflowError，內(nèi)存溢出了，你代碼怎么處理這些異常？ 打印一行錯(cuò)誤日志嗎？或者JDK給你提供了方法讓你能把內(nèi)存釋放掉？ 就算給你提供了，那你知道要釋放哪些內(nèi)存呢？顯然都不是合理的解決方案。那你代碼還不如不處理這種異常。當(dāng)內(nèi)存溢出了，我們通過監(jiān)控等手段發(fā)現(xiàn)內(nèi)存占用量高，然后在去定位問題。

exception是程序能夠處理的異常。 但是需要注意的是catch里面的處理邏輯。實(shí)際很多場景并不是簡單的打印一行錯(cuò)誤日志這么簡單的操作。

比如寫接口，程序在運(yùn)行完主流程后，往數(shù)據(jù)庫寫入一條操作日志，這個(gè)操作日志又不影響主流程，我們就可以把這個(gè)insert try

catch住，insert出現(xiàn)問題了，我們可以發(fā)送一條MQ消息，MQ消息有重試機(jī)制，確保insert操作成功。或者我們可以把失敗的數(shù)據(jù)保存到MySQL異常處理表中，然后運(yùn)行定時(shí)任務(wù)，將運(yùn)行失敗的數(shù)據(jù)同步到對(duì)應(yīng)的業(yè)務(wù)表中。

讀接口，比如c端的一些交互接口，我們不僅要catch住，還要返回一些兜底數(shù)據(jù)。

比如查詢商品列表，當(dāng)調(diào)取商品信息接口查詢商品詳情異常的時(shí)候，我們可以返回一些兜底的商品數(shù)據(jù)，這些商品數(shù)據(jù)可以寫死或者將這部分商品信息維護(hù)到動(dòng)態(tài)配置中心里面；

接下來看一下具體的業(yè)務(wù)應(yīng)該怎么樣處理異常。

讀接口異常處理方式：

先看一下業(yè)務(wù)背景：

這個(gè)是商品詳情頁：包含商品詳情數(shù)據(jù)和評(píng)價(jià)數(shù)據(jù)；首先用戶只有看到商品了才能下單，評(píng)價(jià)信息只是輔助用戶下單，那么當(dāng)查詢商品信息出現(xiàn)問題，系統(tǒng)必須異常，如果僅僅是評(píng)價(jià)信息查詢異常；那頁面最多不展示評(píng)價(jià)信息就好，因?yàn)檫@個(gè)不影響用戶下單；（但是評(píng)價(jià)系統(tǒng)也要保證服務(wù)穩(wěn)定性的，畢竟是c端交互的接口）

看一下代碼，代碼的邏輯也比較簡單。先查詢商品數(shù)據(jù)，然后查詢這個(gè)商品的評(píng)價(jià)數(shù)據(jù)，最后拼接數(shù)據(jù)，返回。

問題：

如果查詢商品評(píng)價(jià)信息接口異常了，那么我們整個(gè)接口都要發(fā)生異常。商品數(shù)據(jù)是用戶下單必須要展示的數(shù)據(jù)，評(píng)價(jià)數(shù)據(jù)只是輔助用戶下單的。那為什么查詢?cè)u(píng)價(jià)數(shù)據(jù)異常了要影響商品詳情頁的頁面數(shù)據(jù)展示呢？

我們將代碼改成如下形式：

將查詢?cè)u(píng)價(jià)信息的邏輯try{} catch住，當(dāng)查詢?cè)u(píng)價(jià)數(shù)據(jù)異常后，我們的頁面降級(jí)，不在展示商品評(píng)價(jià)信息。 不是評(píng)價(jià)數(shù)據(jù)不重要，只是我們?yōu)榱司S護(hù)系統(tǒng)的穩(wěn)定性，不能讓評(píng)價(jià)數(shù)據(jù)影響到整個(gè)商品詳情的頁面展示。

看另一個(gè)場景： 查詢商品列表的頁面，當(dāng)查詢商品列表出現(xiàn)異常了，這個(gè)頁面出現(xiàn)系統(tǒng)異?；蛘邥?huì)出現(xiàn)空白頁

有沒有更好的辦法，當(dāng)查詢商品列表數(shù)據(jù)異常了，我們給用戶返回一些兜底數(shù)據(jù)，讓這個(gè)頁面不出現(xiàn)空白，就是系統(tǒng)異常了，也不讓用戶感知到。查詢出來1-2條數(shù)據(jù)和出現(xiàn)空白是2個(gè)概念。

看一下代碼：

分頁查詢商品數(shù)據(jù)。當(dāng)查詢商品列表異常時(shí)，如果是第一頁數(shù)據(jù)我們可以返回兜底數(shù)據(jù)。

問題：

我們將兜底數(shù)據(jù)寫死了，返回的是name為商品的數(shù)據(jù)。 如果以后運(yùn)營或者產(chǎn)品想將兜底商品改成商品1，我們后端需要修改代碼然后發(fā)布上線。有沒有一個(gè)更好的辦法，讓我們不用上線就可以修改這個(gè)兜底數(shù)據(jù)的。 就是動(dòng)態(tài)配置中心，我們可以將兜底數(shù)據(jù)放到動(dòng)態(tài)配置中心里面，當(dāng)數(shù)據(jù)需要修改的時(shí)候，修改配置中心的數(shù)據(jù)就好。

寫接口異常處理方式：

看一下業(yè)務(wù)背景： 用戶點(diǎn)擊提交訂單，流量到達(dá)訂單系統(tǒng)，訂單系統(tǒng)保存訂單數(shù)據(jù)。

看一下代碼：

代碼邏輯是保存訂單數(shù)據(jù)，然后插入數(shù)據(jù)到操作日志表里面。

代碼這么寫有什么問題？

用戶下單，最重要的是保存訂單數(shù)據(jù)，保存完訂單數(shù)據(jù)后，插入操作日志異常，那么整個(gè)服務(wù)異常，用戶下單失敗。 保存訂單數(shù)據(jù)是主流程，保存操作日志數(shù)據(jù)是非主流程，為什么要讓非主流程的代碼邏輯影響到主流程的穩(wěn)定性？

將代碼改成如下形式。將保存操作日志的數(shù)據(jù)try{} catch{}住，這樣即使保存操作日志數(shù)據(jù)異常了，服務(wù)也不會(huì)異常。

問題：

系統(tǒng)異常后，我們將訂單日志數(shù)據(jù)直接丟了。如果客服系統(tǒng)的訂單數(shù)據(jù)來源是操作日志表那？ 用戶下了單，過了一段時(shí)間，發(fā)現(xiàn)自己的訂單有問題，打客服電話，客服通過客服系統(tǒng)去查詢這個(gè)訂單數(shù)據(jù)，客服系統(tǒng)的數(shù)據(jù)來源于訂單日志表，現(xiàn)在這個(gè)數(shù)據(jù)丟掉了，那么客服怎么樣解答用戶的問題？解決保存訂單接口的穩(wěn)定性同時(shí)引入了其他bug。

我們需要將代碼改成如下形式：

保存訂單操作日志的接口我們?nèi)匀籺ry{} catch{}住，當(dāng)出現(xiàn)異常的時(shí)候，我們可以發(fā)送一條MQ消息，這個(gè)MQ消息里面包含訂單日志數(shù)據(jù)，用MQ消息的重試機(jī)制確保數(shù)據(jù)保存到訂單日志表里面。 或者我們可以將訂單日志數(shù)據(jù)寫入到其他表里面，用定時(shí)任務(wù)去輪詢這張表里面的數(shù)據(jù)，將異常的數(shù)據(jù)保存到訂單日志表里面。這個(gè)就是當(dāng)寫入數(shù)據(jù)異常后我們可以用mq或者定時(shí)任務(wù)將數(shù)據(jù)補(bǔ)償。

總結(jié):

1.error異常不需要抓取，抓取了你也沒有合適的辦法處理這部分異常；

2.exception異常不同的業(yè)務(wù)有不同的處理辦法;

你的業(yè)務(wù)如果只是簡單的B端或者運(yùn)營端業(yè)務(wù)，很多場景你都不需要處理異常，甚至都不需要catch；

你的業(yè)務(wù)如果是c端或者是b端的一些核心接口；

讀接口：

1.先確定哪些數(shù)據(jù)是必須要返回的。比如商品詳情頁，商品數(shù)據(jù)是必須要返回的，如果商品數(shù)據(jù)都沒有，那用戶怎么樣下單？而商品的評(píng)價(jià)數(shù)據(jù)，不是這個(gè)數(shù)據(jù)不重要，只是你已經(jīng)知道查詢?cè)u(píng)價(jià)數(shù)據(jù)異常了，但是商品數(shù)據(jù)查詢到了，為了不影響用戶下單，那就降級(jí)，不展示評(píng)價(jià)數(shù)據(jù)。

2.這個(gè)接口如果沒有查詢到數(shù)據(jù)是否要返回一些兜底數(shù)據(jù)。比如商品列表不能返回空白頁，這個(gè)時(shí)候你就需要返回兜底數(shù)據(jù)。這個(gè)兜底數(shù)據(jù)你寫死或者放到動(dòng)態(tài)配置中心里面都可以，但是最好放到動(dòng)態(tài)配置中心里面。

寫接口：

先確定業(yè)務(wù)的核心鏈路是什么，非核心鏈路是什么。非核心鏈路的穩(wěn)定性是否影響到了核心鏈路。

如果你的服務(wù)是訂單系統(tǒng)，對(duì)于用戶下單接口，最重要的就是保存用戶的下單數(shù)據(jù)（核心鏈路），其他數(shù)據(jù)異常了（非核心鏈路），不是這些數(shù)據(jù)不重要而是這些數(shù)據(jù)的異常不能影響用戶下單，后期可以再去補(bǔ)償這些數(shù)據(jù)，可以用MQ或者定時(shí)任務(wù)去補(bǔ)償這部分?jǐn)?shù)據(jù)。