設(shè)備異常處理流程及規(guī)定？1. 如果可以處理，就應(yīng)該早點處理。如果不能處理它，則應(yīng)該將其消化或轉(zhuǎn)換為runtimeException。因為對于應(yīng)用程序系統(tǒng)來說，拋出大量異常是有問題的。我們應(yīng)該從程序開發(fā)

設(shè)備異常處理流程及規(guī)定？

1. 如果可以處理，就應(yīng)該早點處理。如果不能處理它，則應(yīng)該將其消化或轉(zhuǎn)換為runtimeException。因為對于應(yīng)用程序系統(tǒng)來說，拋出大量異常是有問題的。我們應(yīng)該從程序開發(fā)的角度盡可能地控制異常的可能性。

2. 對于檢查異常，如果不能有效地處理它，最好將其作為runtimeException拋出。這也給了上層代碼一個選擇——是否處理它。

3. 對于一個應(yīng)用系統(tǒng)來說，它應(yīng)該有自己的異常處理框架，這樣當異常發(fā)生時，它也可以得到統(tǒng)一的處理風格，并將優(yōu)雅的異常信息反饋給用戶。

在JAVA中捕獲異常后throw自定義異常是不優(yōu)雅的嗎？

事實上，這種方法在很多框架中都有使用

1。Rethrow

自定義異常，用于更好地隔離異常，識別異常類型、ID、自定義消息和日志

2。對第三方庫的異常進行打包和抽象，以保持與框架異常定義的一致性，方便框架處理不同的異常

3。Restful API，統(tǒng)一異常管理

對于拋出的異常，檢查異常應(yīng)該與方法耦合，特別是接口中定義的方法影響很大，使用不夠靈活。如果不拋出異常，則必須嘗試捕獲全屏。我目前的方法是，除非拋出的異常需要由調(diào)用層顯式處理，否則用戶定義的異常將繼承runtimeException并在頂級調(diào)用中進行try catch。這樣，方法的聲明和使用就簡單多了。事實上，我認為最重要的是團隊的一致性。