把 try 里的異常都吞掉)
「Java 進(jìn)階之路」系列 Day28寫在前面try-catch-finally看起來是最基礎(chǔ)的語法但只要return和finally混在一起用行為就開始變得反直覺。這篇把幾個(gè)具體場(chǎng)景過一遍講清楚finally到底是在什么時(shí)機(jī)、以什么方式介入了方法的返回過程。一、是什么finally 幾乎總會(huì)執(zhí)行finally塊的設(shè)計(jì)初衷是無論try塊是正常結(jié)束、提前return、還是拋出了異常都要執(zhí)行的收尾邏輯典型場(chǎng)景是關(guān)閉文件流、釋放鎖這類必須執(zhí)行的清理動(dòng)作。幾乎總會(huì)執(zhí)行這個(gè)說法留了個(gè)口子——只有System.exit()直接終止JVM進(jìn)程、或者JVM自身崩潰這種極端情況下finally才會(huì)被跳過正常的業(yè)務(wù)代碼邏輯里可以認(rèn)為它是必定執(zhí)行的。二、為什么會(huì)有坑return 的真正時(shí)機(jī)publicstaticinttest(){try{return1;}finally{return2;}}System.out.println(test());// 輸出2不是1try塊執(zhí)行到return 1這行計(jì)算好返回值1 先暫存起來 還沒真正返回給調(diào)用方開始執(zhí)行finally塊finally塊里也有return語句用finally的返回值2 直接覆蓋掉之前暫存的1方法最終返回2關(guān)鍵在于try塊里的return語句并不是立刻把值交出去而是先把返回值計(jì)算好、暫存起來然后再去執(zhí)行finally塊。如果finally塊里也有一條return語句這條return會(huì)直接把之前暫存的值覆蓋掉最終返回的是finally里的值。這也是為什么幾乎所有代碼規(guī)范都建議不要在finally里寫return——它的優(yōu)先級(jí)比try/catch里的return更高很容易在不經(jīng)意間覆蓋掉本該返回的結(jié)果而且極難在代碼審查時(shí)一眼看出問題。一個(gè)更隱蔽的例子finally 修改變量不一定能改變返回值publicstaticinttest2(){inti1;try{returni;}finally{i2;// 修改變量i但不寫return}}System.out.println(test2());// 輸出1不是2這里沒有在finally里寫return但很多人會(huì)誤以為finally改了i返回值也應(yīng)該跟著變成2。實(shí)際上執(zhí)行到try里的return i時(shí)i當(dāng)前的值1已經(jīng)被復(fù)制了一份暫存起來作為這個(gè)方法準(zhǔn)備返回的結(jié)果隨后執(zhí)行finally塊i 2這行改的是變量i本身并不會(huì)去追溯、修改那份已經(jīng)復(fù)制出去、暫存好的返回值。只有finally里再顯式寫一條return語句才會(huì)真正覆蓋返回結(jié)果單純?cè)趂inally里修改一個(gè)基本類型變量的值不會(huì)影響已經(jīng)暫存的返回值。如果try里return的是一個(gè)引用類型對(duì)象、finally里修改的是這個(gè)對(duì)象內(nèi)部的字段而不是重新賦值這個(gè)引用情況又不一樣——因?yàn)闀捍娴氖沁@個(gè)對(duì)象的引用本身finally對(duì)它內(nèi)部字段的修改調(diào)用方拿到返回值后是能感知到的。這里的關(guān)鍵始終是暫存的到底是什么基本類型暫存的是值的拷貝引用類型暫存的是引用本身。最容易被打問號(hào)的坑finally 里的 return 會(huì)把異常也吞掉publicstaticinttest3(){try{thrownewRuntimeException(出錯(cuò)了);}finally{return2;// 這個(gè)return會(huì)把上面的異常直接吞掉}}System.out.println(test3());// 輸出2異常完全消失調(diào)用方感知不到出過錯(cuò)這是最危險(xiǎn)的一種情況try塊里拋出的異常本來應(yīng)該繼續(xù)往外傳播但如果finally塊里恰好也有一條return語句這條return會(huì)直接終止異常的傳播過程異常被無聲無息地吞掉調(diào)用方完全不知道方法內(nèi)部曾經(jīng)拋出過異常只會(huì)拿到finally返回的這個(gè)值。這也是為什么不要在finally里寫return這條建議要格外強(qiáng)調(diào)——它不僅會(huì)覆蓋try/catch里準(zhǔn)備好的正常返回值還會(huì)把原本應(yīng)該繼續(xù)拋出的異常直接吃掉屬于比覆蓋返回值更隱蔽、更危險(xiǎn)的一類問題。三、怎么用一條經(jīng)驗(yàn)總結(jié)綜合以上幾種情況實(shí)際寫代碼時(shí)只需要記住一條經(jīng)驗(yàn)finally塊只用來做資源清理、釋放鎖這類收尾動(dòng)作永遠(yuǎn)不要在finally里寫return或者throw語句。只要遵守這一條try-catch-finally組合起來的行為就會(huì)符合直覺——try正常執(zhí)行完或者提前return走try/catch那部分的返回值和異常finally執(zhí)行完清理邏輯后安靜地把控制權(quán)交還不做任何搶戲的動(dòng)作。四、面試追問Q1try 里有 returnfinally 里也有 return最終返回的是哪個(gè)返回的是finally里的值。try塊的return語句會(huì)先計(jì)算好返回值并暫存但不會(huì)立刻返回而是先執(zhí)行finally塊如果finally塊里也有return語句會(huì)直接用這個(gè)新的返回值覆蓋掉之前暫存的值所以最終返回的是finally里return的結(jié)果。Q2try 里 return 了一個(gè)基本類型變量finally 里修改了這個(gè)變量的值返回值會(huì)變嗎不會(huì)變前提是finally里沒有再寫return語句。try塊執(zhí)行return時(shí)變量當(dāng)前的值已經(jīng)被復(fù)制了一份暫存起來作為準(zhǔn)備返回的結(jié)果之后finally塊對(duì)變量本身的修改不會(huì)影響這份已經(jīng)暫存的拷貝。只有finally里顯式再寫一條return語句才會(huì)真正覆蓋最終的返回結(jié)果。Q3如果 try 里的返回值是一個(gè)對(duì)象引用finally 里修改了這個(gè)對(duì)象內(nèi)部的字段調(diào)用方能感知到嗎能感知到。因?yàn)閠ry塊return時(shí)暫存的是這個(gè)對(duì)象的引用本身不是對(duì)象內(nèi)容的深拷貝finally里如果修改的是這個(gè)引用指向的對(duì)象內(nèi)部的字段而不是把引用重新指向另一個(gè)新對(duì)象調(diào)用方拿到的返回值和finally修改的是同一個(gè)對(duì)象自然能看到這些字段變化。這一點(diǎn)和基本類型變量的值不會(huì)受finally影響是不同的機(jī)制區(qū)分標(biāo)準(zhǔn)在于暫存的到底是值的拷貝還是對(duì)象的引用。Q4為什么說 finally 里的 return 會(huì)把 try 里拋出的異常吞掉因?yàn)閒inally塊的return語句會(huì)直接終止整個(gè)方法的執(zhí)行流程、把控制權(quán)作為正常返回交還給調(diào)用方這個(gè)過程會(huì)覆蓋并終止掉本應(yīng)該繼續(xù)向外傳播的異常。如果try塊里拋出了異常而finally塊恰好也有一條return語句被執(zhí)行到這個(gè)異常就會(huì)被無聲無息地吞掉調(diào)用方完全感知不到方法內(nèi)部曾經(jīng)出過錯(cuò)只會(huì)拿到finally返回的值這是一種非常隱蔽、容易被忽視的問題。Q5寫 try-catch-finally 時(shí)應(yīng)該遵循什么原則避免這些坑finally塊應(yīng)該只用來做資源清理、釋放鎖這類收尾動(dòng)作不應(yīng)該在finally里寫return語句也不應(yīng)該在finally里拋出新的異常同樣會(huì)覆蓋掉try/catch里原本要拋出的異常。只要遵守這條原則try/catch里準(zhǔn)備好的返回值和異常就不會(huì)被finally意外覆蓋或者吞掉代碼行為也更符合直覺、更容易被正確理解。下一篇預(yù)告Day29 講字節(jié)流和字符流的區(qū)別——為什么處理文本文件更推薦用字符流BufferedInputStream這類帶緩沖的實(shí)現(xiàn)又是靠什么變快的。 finally 里的 return，會(huì)把 try 里的異常都吞掉
「Java 進(jìn)階之路」系列 Day28寫在前面try-catch-finally看起來是最基礎(chǔ)的語法但只要return和finally混在一起用行為就開始變得反直覺。這篇把幾個(gè)具體場(chǎng)景過一遍講清楚finally到底是在什么時(shí)機(jī)、以什么方式介入了方法的返回過程。一、是什么finally 幾乎總會(huì)執(zhí)行finally塊的設(shè)計(jì)初衷是無論try塊是正常結(jié)束、提前return、還是拋出了異常都要執(zhí)行的收尾邏輯典型場(chǎng)景是關(guān)閉文件流、釋放鎖這類必須執(zhí)行的清理動(dòng)作。幾乎總會(huì)執(zhí)行這個(gè)說法留了個(gè)口子——只有System.exit()直接終止JVM進(jìn)程、或者JVM自身崩潰這種極端情況下finally才會(huì)被跳過正常的業(yè)務(wù)代碼邏輯里可以認(rèn)為它是必定執(zhí)行的。二、為什么會(huì)有坑return 的真正時(shí)機(jī)publicstaticinttest(){try{return1;}finally{return2;}}System.out.println(test());// 輸出2不是1try塊執(zhí)行到return 1這行計(jì)算好返回值1 先暫存起來 還沒真正返回給調(diào)用方開始執(zhí)行finally塊finally塊里也有return語句用finally的返回值2 直接覆蓋掉之前暫存的1方法最終返回2關(guān)鍵在于try塊里的return語句并不是立刻把值交出去而是先把返回值計(jì)算好、暫存起來然后再去執(zhí)行finally塊。如果finally塊里也有一條return語句這條return會(huì)直接把之前暫存的值覆蓋掉最終返回的是finally里的值。這也是為什么幾乎所有代碼規(guī)范都建議不要在finally里寫return——它的優(yōu)先級(jí)比try/catch里的return更高很容易在不經(jīng)意間覆蓋掉本該返回的結(jié)果而且極難在代碼審查時(shí)一眼看出問題。一個(gè)更隱蔽的例子finally 修改變量不一定能改變返回值publicstaticinttest2(){inti1;try{returni;}finally{i2;// 修改變量i但不寫return}}System.out.println(test2());// 輸出1不是2這里沒有在finally里寫return但很多人會(huì)誤以為finally改了i返回值也應(yīng)該跟著變成2。實(shí)際上執(zhí)行到try里的return i時(shí)i當(dāng)前的值1已經(jīng)被復(fù)制了一份暫存起來作為這個(gè)方法準(zhǔn)備返回的結(jié)果隨后執(zhí)行finally塊i 2這行改的是變量i本身并不會(huì)去追溯、修改那份已經(jīng)復(fù)制出去、暫存好的返回值。只有finally里再顯式寫一條return語句才會(huì)真正覆蓋返回結(jié)果單純?cè)趂inally里修改一個(gè)基本類型變量的值不會(huì)影響已經(jīng)暫存的返回值。如果try里return的是一個(gè)引用類型對(duì)象、finally里修改的是這個(gè)對(duì)象內(nèi)部的字段而不是重新賦值這個(gè)引用情況又不一樣——因?yàn)闀捍娴氖沁@個(gè)對(duì)象的引用本身finally對(duì)它內(nèi)部字段的修改調(diào)用方拿到返回值后是能感知到的。這里的關(guān)鍵始終是暫存的到底是什么基本類型暫存的是值的拷貝引用類型暫存的是引用本身。最容易被打問號(hào)的坑finally 里的 return 會(huì)把異常也吞掉publicstaticinttest3(){try{thrownewRuntimeException(出錯(cuò)了);}finally{return2;// 這個(gè)return會(huì)把上面的異常直接吞掉}}System.out.println(test3());// 輸出2異常完全消失調(diào)用方感知不到出過錯(cuò)這是最危險(xiǎn)的一種情況try塊里拋出的異常本來應(yīng)該繼續(xù)往外傳播但如果finally塊里恰好也有一條return語句這條return會(huì)直接終止異常的傳播過程異常被無聲無息地吞掉調(diào)用方完全不知道方法內(nèi)部曾經(jīng)拋出過異常只會(huì)拿到finally返回的這個(gè)值。這也是為什么不要在finally里寫return這條建議要格外強(qiáng)調(diào)——它不僅會(huì)覆蓋try/catch里準(zhǔn)備好的正常返回值還會(huì)把原本應(yīng)該繼續(xù)拋出的異常直接吃掉屬于比覆蓋返回值更隱蔽、更危險(xiǎn)的一類問題。三、怎么用一條經(jīng)驗(yàn)總結(jié)綜合以上幾種情況實(shí)際寫代碼時(shí)只需要記住一條經(jīng)驗(yàn)finally塊只用來做資源清理、釋放鎖這類收尾動(dòng)作永遠(yuǎn)不要在finally里寫return或者throw語句。只要遵守這一條try-catch-finally組合起來的行為就會(huì)符合直覺——try正常執(zhí)行完或者提前return走try/catch那部分的返回值和異常finally執(zhí)行完清理邏輯后安靜地把控制權(quán)交還不做任何搶戲的動(dòng)作。四、面試追問Q1try 里有 returnfinally 里也有 return最終返回的是哪個(gè)返回的是finally里的值。try塊的return語句會(huì)先計(jì)算好返回值并暫存但不會(huì)立刻返回而是先執(zhí)行finally塊如果finally塊里也有return語句會(huì)直接用這個(gè)新的返回值覆蓋掉之前暫存的值所以最終返回的是finally里return的結(jié)果。Q2try 里 return 了一個(gè)基本類型變量finally 里修改了這個(gè)變量的值返回值會(huì)變嗎不會(huì)變前提是finally里沒有再寫return語句。try塊執(zhí)行return時(shí)變量當(dāng)前的值已經(jīng)被復(fù)制了一份暫存起來作為準(zhǔn)備返回的結(jié)果之后finally塊對(duì)變量本身的修改不會(huì)影響這份已經(jīng)暫存的拷貝。只有finally里顯式再寫一條return語句才會(huì)真正覆蓋最終的返回結(jié)果。Q3如果 try 里的返回值是一個(gè)對(duì)象引用finally 里修改了這個(gè)對(duì)象內(nèi)部的字段調(diào)用方能感知到嗎能感知到。因?yàn)閠ry塊return時(shí)暫存的是這個(gè)對(duì)象的引用本身不是對(duì)象內(nèi)容的深拷貝finally里如果修改的是這個(gè)引用指向的對(duì)象內(nèi)部的字段而不是把引用重新指向另一個(gè)新對(duì)象調(diào)用方拿到的返回值和finally修改的是同一個(gè)對(duì)象自然能看到這些字段變化。這一點(diǎn)和基本類型變量的值不會(huì)受finally影響是不同的機(jī)制區(qū)分標(biāo)準(zhǔn)在于暫存的到底是值的拷貝還是對(duì)象的引用。Q4為什么說 finally 里的 return 會(huì)把 try 里拋出的異常吞掉因?yàn)閒inally塊的return語句會(huì)直接終止整個(gè)方法的執(zhí)行流程、把控制權(quán)作為正常返回交還給調(diào)用方這個(gè)過程會(huì)覆蓋并終止掉本應(yīng)該繼續(xù)向外傳播的異常。如果try塊里拋出了異常而finally塊恰好也有一條return語句被執(zhí)行到這個(gè)異常就會(huì)被無聲無息地吞掉調(diào)用方完全感知不到方法內(nèi)部曾經(jīng)出過錯(cuò)只會(huì)拿到finally返回的值這是一種非常隱蔽、容易被忽視的問題。Q5寫 try-catch-finally 時(shí)應(yīng)該遵循什么原則避免這些坑finally塊應(yīng)該只用來做資源清理、釋放鎖這類收尾動(dòng)作不應(yīng)該在finally里寫return語句也不應(yīng)該在finally里拋出新的異常同樣會(huì)覆蓋掉try/catch里原本要拋出的異常。只要遵守這條原則try/catch里準(zhǔn)備好的返回值和異常就不會(huì)被finally意外覆蓋或者吞掉代碼行為也更符合直覺、更容易被正確理解。下一篇預(yù)告Day29 講字節(jié)流和字符流的區(qū)別——為什么處理文本文件更推薦用字符流BufferedInputStream這類帶緩沖的實(shí)現(xiàn)又是靠什么變快的。