小總結(jié)

拋出異常：

創(chuàng)建異常對象，封裝異常信息然后通過throw將異常對象傳遞給調(diào)用者。

不對異常進(jìn)行處理只對異常進(jìn)行拋出是非常不負(fù)責(zé)任的表現(xiàn)可以稱為渣男。

但是可以通過主動(dòng)拋出異常對一些jvm虛擬機(jī)識別不出來的異常進(jìn)行拋出。

手動(dòng)拋出異常舉例

public static void main(String[] args) throws Exception {
        int age = 0;
        age = -100;
        if(age<0)
        {
            Exception e = new Exception();//創(chuàng)建異常對象
            throw e;//拋出異常
        }
        System.out.println(age);
    }

這個(gè)例子在常理中年齡是不能小于零的所以要手動(dòng)拋出異常。

捕獲異常：

對異常進(jìn)行捕獲然后進(jìn)行指定方式的處理

throw與throws的區(qū)別：

1.拋出的東西不同：throw拋出的是具體的異常對象，而throws拋出的是抽象的異常類。

2.使用位置不同：throw一般用在方法體中，也可用在代碼塊中，throws只能用在方法聲明括號后面。

Java中的異常處理：何時(shí)拋出異常，何時(shí)捕獲異常？

在看hadoop源碼時(shí)，想想自己最近在做的那個(gè)系統(tǒng)，發(fā)現(xiàn)很多異常處理的方式不對，還是按照傳統(tǒng)的異常處理方式（即：采用返回值來標(biāo)識程序出現(xiàn)的異常情況）。而hadoop中很多方法的聲明是有異常拋出的，而我的系統(tǒng)中的很多方法的聲明都沒有拋出異常。只是判斷了異常情況，并輸出了錯(cuò)誤提示，但是并沒有拋出異常。

org.apache.hadoop.hdfs.protocol包下的Block類的readFields()方法：

public void readFields(DataInput in) throws IOException {
    this.blockId = in.readLong();
    this.numBytes = in.readLong();
    this.generationStamp = in.readLong();
    if (numBytes < 0) {
      throw new IOException("Unexpected block size: " + numBytes);//拋出異常，要是的話就不會拋出，而只是System.out.println錯(cuò)誤提示，
    }

1.如果方法聲明名里面有throws異常，那么方法體里面可以不拋出異常。

因?yàn)榭梢栽诜椒暶髦邪惓Ｕf明，但實(shí)際上卻不拋出！這樣做的好處是，為異常先占個(gè)位置，以后就可以拋出這種異常而不用修改修改已有的代碼。在定義抽象基類和接口時(shí)這種能力很重要，這樣派生類或接口實(shí)現(xiàn)類就能夠拋出這些預(yù)先聲明的異常。

2.為什么有的方法聲明里面沒有throws，但方法體里面卻拋出了異常？

從RuntimeException繼承的異常，可以在沒有異常說明throws的情況下被拋出！對于Runtime異常（也稱為非檢查的異常unchecked exception），編譯器不需要異常說明。只能在代碼中忽略RuntimeException（及其子類）類型的異常，其他類型的異常的處理都是由編譯器強(qiáng)制實(shí)施的。究其原因，RuntimeException代表的是編程錯(cuò)誤。

3.運(yùn)行時(shí)異常會被Java虛擬機(jī)自動(dòng)拋出！

1. 異常處理基礎(chǔ)

1.1 System.out.println是高代價(jià)的。調(diào)用System.out.println會降低系統(tǒng)吞吐量。

1.2 在生產(chǎn)環(huán)境中別用異常的printStackTrace()方法。printStackTrace默認(rèn)會把調(diào)用的堆棧打印到控制臺上，在生產(chǎn)環(huán)境中訪問控制臺是不現(xiàn)實(shí)的。

2. 異常處理基本原則

2.1 如果你不能處理異常，不要捕獲該異常。

2.2 如果要捕獲，應(yīng)在離異常源近的地方捕獲它。

2.3 不要吞沒你捕獲的異常。

*（就是捕獲的異常，但是什么也不做）

2.4 除非你要重新拋出異常，否則把它log起來。

2.5 當(dāng)一個(gè)異常被重新包裝，然后重新拋出的時(shí)候，不要打印statck trace。

2.6 用自定義的異常類，不要每次需要拋出異常的時(shí)候都拋出java.lang.Exception。方法的調(diào)用者可以通過throws知道有哪些異常需要處理--所以它是自我描述的。

2.7 如果你編寫業(yè)務(wù)邏輯，對于終端用戶無法修復(fù)的錯(cuò)誤，系統(tǒng)應(yīng)該拋出非檢查的異常（unchecked exception）；如果你編寫一個(gè)第三方的包給其他的開發(fā)人員用，對于不可修復(fù)的錯(cuò)誤要用需要檢查的異常（checked exception）。

2.8 絕對不要因?yàn)閷憈hrows語句會讓你用起來不舒服，而不聲明需要檢查的異常。

2.9 應(yīng)用級別的錯(cuò)誤或不可修復(fù)的系統(tǒng)異常用非檢查的異常（unchecked exception）拋出。

*（注意是錯(cuò)誤，意味著不可修復(fù)，比如配置文件錯(cuò)誤）

2.10 根據(jù)異常的粒度組織你的方法

以上為個(gè)人經(jīng)驗(yàn)，希望能給大家一個(gè)參考，也希望大家多多支持腳本之家。

最新評論