異常規范

異常介紹

Throwable

所有Exception和Error的父類.

Error

致命錯誤. 項目自身存在問題, 諸如格式有問題, 編譯版本不對, 堆棧溢出等, 項目在出現ERROR的情況下是不應該運行的. 同時, 程序遇到Error時, 程序不需要, 通常也是沒有能力做處理的, 只能夠停止程序針對項目或者運行環境做人工處理才行.

Exception

區別于Error, 是程序可以自己處理的異常. Exception的子類中, 特殊的RuntimeException被稱為運行時異常, 也叫非受檢異常; 其他的子類包括Exception類本身都叫受檢異常

受檢異常

Java編譯器會檢查它，也就是說，當程序中可能出現這類異常，要么用try-catch語句捕獲它，要么用throws子句聲明拋出它，否則編譯不會通過。

非受檢異常(運行時異常)

不需要強制catch或者throw的異常.

程序中如何使用異常

程序中我們主要關注受檢異常和運行時異常的使用

一些原則, 這些原則并不獨立, 互相之間有照應或者補充:

發生可恢復錯誤的拋出受檢異常，程序錯誤就拋出運行時異常

盡量使用運行時異常. 從保障代碼簡潔, 清晰, 有意義的角度上來說.

注意絕對不是無腦把受檢異常換為運行時異常.

很多時候我們要延遲處理異常: 比如我們的一個受檢異常在層次很深的地方拋出, 但是我們在代碼層次很高的地方才能做處理, 那么受檢異常會出現在代碼調用的每一層. 這非常繁瑣, 也不清晰.

謹慎拋出受檢異常.

受檢異常是不受歡迎的.

除非你認為你是在強調這個異常, 調用者在大多數情況下需要重點關注這個異常并catch這個異常并做處理.

使用運行時異常帶來的簡潔并不能夠彌補開發人員忽略了這個異常帶來的問題時.

作為定位是類庫的模塊, 盡量使用運行時異常, 并對java低層異常封裝, 拋出類庫特有的概括性的異常.

當站在調用者的角度, 可以獲悉這個類庫有哪幾種異常, 出現時代表什么了.

移位類庫的調用很多時候跟業務沒有關系, 當出現錯誤時, 通常是因為我們的代碼漏洞造成的, 這并不能簡單通過try_catch進行恢復, 所以盡量不使用受檢異常.

作為定位是服務的模塊, 可以使用一些受檢異常.

因為當調用服務出現錯誤, 一般是一個可以解釋的業務錯誤, 如果是想要調用者非常注意的錯誤, 可以使用受檢異常.

服務的調用一般代碼層次比較淺, 并且是和業務比較相關的.

業務異常需要單獨封裝成新的異常來表達一類或者一個模塊的業務錯誤, 可以使用受檢異常. 但也參照1, 2, 3

可以把一些非業務異常封裝成為業務異常, 如果你知道在這個地方這種非業務異常在業務上可以表達一些含義.

比如某個位置拋出了json解析異常, 我們可以說傳入的某個數據格式是錯誤的.

為了給大家建立異常體系結構, 業務異常定義為受檢異常, 強制讓大家關注下.

非業務異常, 代碼底層異常, 如果出現的話可以定義為代碼bug的, 使用運行時異常

即使沒有catch住的后果是在系統運行時拋給了用戶, 也不應該catch. 當然在項目中需要一個最高層次的異常處理, 對非業務異常統一catch記錄報警而不要暴露給用戶

業務異常如果可以, 不要跨層(跨模塊)

比如

controller -> service -> adaptor -> RPC

PRC 拋出的異常, 應該在adaptor或者service做處理封裝新的異常, 不要讓controller直面RPC的異常.

異常應該攜帶更多信息.

尤其對業務異常來說, 知道異常發生時的業務數據是很重要的, 方便查找定位問題.

在api層(controller層), 將一些業務異常封裝為API異常, 這類異常將直接給用戶api異常的提示, 且有時可以認為這些異常是正常的, 不需要報警的.

有效的業務異常類劃分和異常code定義, 有助于統一處理異常時區別異常的等級合適否需要報警.

在設計異常時請考慮這一點.

如果不知道自己的異常應該是使用受檢異常還是運行時異常, 使用運行時異常.

先報出錯誤, 不做對未知的設計

如何處理異常

絕對禁止catch后什么都不做!

在catch之后封裝成新異常拋出的時候, 不要記錄日志. 因為你拋出了, 會有上層來處理記錄日志, 只要沒有1這種情況, 總會有信息的. 這里再記錄日志就重復了.

在需要時一定要使用上finally

處理異常時記錄的日志一般要把異常的堆棧給記錄下來.

總結

以上是生活随笔為你收集整理的java 异常 规范_java 异常规范的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。