跳到主要內容

Effective Java - Exceptions

本篇收集觀看Effective Java針對Exceptions章節後所整理的心得。

Use checked exceptions for recoverable conditions and runtime exceptions for programming errors

這個Item在強調例外的使用時機,包含

  • Checked Exceptions應用在recoverable conditions
  • Unchecked(Runtime) Exception應用在programming errors

下一個問題就是怎麼定義recoverable conditions與programming errors。我分享笑談軟體工程:例外處理設計的逆襲中的觀點:

  • Programming errors: design fault造成的,通常代表是bug;因為是bug,所以retry 1億次也還是錯的。
  • Recoverable conditions: component fault造成的,可能是軟體元件、硬體元件突然發生故障,或與其溝通的過程中發生故障而導致的暫態缺陷,透過retry是有機會修復的。如果是永久缺陷,可能就需要排除原因才有機會執行成功。

根據上面的定義,就可以知道什麼時候該拋checked exception,什麼時候該拋unchecked exception了。對應到REST API的回應結果,unchecked exception預設通常都會是5xx錯誤,而checked exception就需要交給client去識別,是屬於需要user介入處理的4xx錯誤,還是server暫時的5xx錯誤。

除此之外,這個Item還有提到幾個設計要注意的事情:

  • 按照慣例,Error應保留給JVM使用,用以表明程序無法繼續執行的情況。所以開發人員通常不該去Extend Error。
  • 例外本身是有著設計上的代表意義,可以在類別上定義能供給Client做進一步處理的介面。不建議Client使用例外本身的字串訊息去做例外處理,因為字串訊息說變就變,程式容易出問題。

Reference:

Favor the use of standard exceptions

與之前Favor the use of standard functional interfaces強調概念類似,盡量reuse現有東西。書中的範例主要都是針對unchecked exception,去說明適用情境:

  • NullPointerException: 不允許輸入參數為null時,就會使用它。可以直接使用Objects.requireNonNull去做檢查。
  • IndexOutOfBoundsException: 輸入參數超過可接受的範圍大小,就會使用它。
  • IllegalArgumentException: 輸入參數不合法,就會使用它,但請撇除上面2個情境。
  • llegalStateException: 當method在不適當的時候被呼叫,就會使用它。其實以物件命名想表達的是物件可能處於error state而無法正常工作,因而拋出llegalStateException。有的時候,這個例外我也有看過被用在絕對不可能發生的情況下去拋出llegalStateException;不過應該要盡量避免這種情境,因為單元測試可能寫不出來。StackOverflow有人對javadoc和effective java描述的使用情境認為有所不同,有興趣可以看這裡,我認為effective java描述的情境可應用的場合會比javadoc廣泛拉。
  • UnsupportedOperationException: 呼叫了不支援的method,就會使用它。我想這個例外,應該也適用於某一個method接收http method,但不支援PUT的時候,client卻傳了PUT的情境吧?
  • ConcurrentModificationException: 如果某個method偵測到multiple threads存取時,就有可能會拋這個例外。書中是說,這個是提示意味不一定準確,而我也沒拋過這個例外,因為通常會去避免發生這種情境,而不會做複雜的檢查。
最後就是這個item也有提到不要直接使用Exception、Throwable、RuntimeException或Error,我認為其實是要呼應Item 73: Throw exceptions appropriate to the abstraction。

Reference:

  1.  Effective Java, 3/e, Item 72。

Throw exceptions appropriate to the abstraction

這個Item講了幾個重要概念:

  1. 要將例外從某個物件拋出去的時候,應該拋出與這個物件相襯的例外,而不要直接將底層來的例外拋出去。這個是要避免client與實作細節直接相依而很容易造成改變。除非這個底層例外對於更上層來說,也是合適的例外。
  2. 將例外轉換且重新包裝(exception wrapping)的時候,要將底層例外設為新例外的cause,以利於client去做完整的log或其它處理。
  3. 勿濫用這個重新包裝機制,盡量消除會造成發生底層例外的原因。例如先做precheck,避免呼叫底層API;或者是在原先API發生問題的時候,進行例外處理,讓服務不會受到中斷,並且log以便之後備查。
第一點與第二點非常同意。以第一點來說,通常我們以不同模組、階層的角度去設計對應的例外,不同模組、階層以Clean Architecture來說,如Gateway、Domain、UseCase layer等,會設計不同的Checked Exception並搭配Homogeneous Exception(同質例外)降低介面演進的機會。關於Homogeneous Exception(同質例外)可以參考搞笑談軟工提及的內容。

第三點的話,我就會看情況而決定。假如我需要多做precheck或者是在API發生問題的時候去讓服務可以正常使用,這些勢必會額外增加開發與維護成本。

Reference:

  1.  Effective Java, 3/e, Item 73。

Strive for failure atomicity

這個Item主要在宣導「在工作失敗時,要努力讓物件的狀態完好如呼叫前」。如果method滿足這個條件,就可以稱為具有failure-atomic的method。(Note.要考慮的不只有待操作的物件,應還有做為輸入參數的物件)

第一個方法是操作Immutable object。因為它不會被改變,自然而然就滿足所謂的failure-atomic。依照過往經驗,如果要回傳一個Collection,盡量讓它是Immutable object只用於計算,並避免直接的修改造成side effect。

第二個方法就是在造成物件狀態改變之前,做precheck。假如不做檢查讓物件進入了錯誤的狀態,反而可能會衍生更多問題,且不好debug。

第三個方法就是先把物件複製一份在操作。就算發生問題,也不會影響到原本的物件狀態。

最後一個方法,就是要實做一段recovery code,好讓發生問題時,可以rollback回原本的狀態。像是使用資料庫的Transaction,或操作檔案前先複製一份,有問題在還原檔案等等。

使用這些方法,都要注意一下“代價”與“多執行緒存取”的問題。像要複製物件或準備環原點,都會存在著性能開銷,且程式碼往往會複雜一些些;比較低成本的Immutable object不一定適用於各種情況;precheck則大部分情況都有可能要注意多執行緒的存取,假如是依賴目標物件的狀態做precheck的話。

另外,書中有建議,如果無法滿足failure-atomic的method,“建議”要寫註解讓用的人知道。

Reference:

  1.  Effective Java, 3/e, Item 76。

Don't ignore exceptions

這個是大家都知道的“不該忽略例外”,但卻都會忽略例外的處理,或者是亂處理。如果有裝像SonarLint檢查工具,在你沒處理例外時,它一定會通知你。沒去處理例外最大的問題,就是當它發生問題的時候,你完全不會知道;針對這種Bad Smell可以參考link內容去做對應的重構。除了沒處理的情況外,我這裡也列一些可能亂處理的情況供大家參考:

  • Dummy handler: link
  • Exceptions should be either logged or rethrown but not both: link

留言

這個網誌中的熱門文章

解決RobotFramework從3.1.2升級到3.2.2之後,Choose File突然會整個Hand住的問題

考慮到自動測試環境的維護,我們很久以前就使用java去執行robot framework。前陣子開始處理從3.1.2升級到3.2.2的事情,主要先把明確的runtime語法錯誤與deprecate item處理好,這部分內容可以參考: link 。 直到最近才發現,透過SeleniumLibrary執行Choose File去上傳檔案的動作,會導致測試案例timeout。本篇文章主要分享心路歷程與解決方法,我也送了一條issue給robot framework: link 。 我的環境如下: RobotFramework: 3.2.2 Selenium: 3.141.0 SeleniumLibrary: 3.3.1 Remote Selenium Version: selenium-server-standalone-3.141.59 首先並非所有Choose File的動作都會hang住,有些測試案例是可以執行的,但是上傳一個作業系統ISO檔案一定會發生問題。後來我透過wireshark去比對新舊版本的上傳動作,因為我使用 Remote Selenium ,所以Selenium會先把檔案透過REST API發送到Remote Selenium Server上。從下圖我們可以發現,在3.2.2的最後一個TCP封包,比3.1.2大概少了500個bytes。 於是就開始了我trace code之路。包含SeleniumLibrary產生要送給Remote Selenium Server的request內容,還有HTTP Content-Length的計算,我都確認過沒有問題。 最後發現問題是出在socket API的使用上,就是下圖的這支code: 最後發現可能因為開始使用nio的方式送資料,但沒處理到尚未送完的資料內容,而導致發生問題。加一個loop去做計算就可以解決了。 最後我有把解法提供給robot framework官方,在他們出新的版本之前,我是將改完的_socket.py放在我們自己的Lib底下,好讓我們測試可以正常進行。(shutil.py應該也是為了解某個bug而產生的樣子..)

Show NIC selection when setting the network command with the device option

 Problem  在answer file中設定網卡名稱後,安裝時會停在以下畫面: 所使用的command參數如下: network --onboot = yes --bootproto =dhcp --ipv6 =auto --device =eth1 Diagnostic Result 這樣的參數,以前試驗過是可以安裝完成的。因此在發生這個問題後,我檢查了它的debug console: 從console得知,eth1可能是沒有連接網路線或者是網路太慢而導致的問題。後來和Ivy再三確認,有問題的是有接網路線的網卡,且問題是發生在activate階段: Solution 我想既然有retry應該就有次數或者timeout限制,因此發現在Anaconda的說明文件中( link ),有提到dhcptimeout這個boot參數。看了一些人的使用範例,應該是可以直接串在isolinux.cfg中,如下: default linux ksdevice = link ip =dhcp ks =cdrom: / ks.cfg dhcptimeout = 90 然而我在RHEL/CentOS 6.7與6.8試驗後都無效。 因此我就拿了顯示的錯誤字串,問問Google大師,想找一下Anaconda source code來看一下。最後找到別人根據Anaconda code修改的版本: link ,關鍵在於setupIfaceStruct函式中的setupIfaceStruct與readNetConfig: setupIfaceStruct: 會在dhcp時設定dhcptimeout。 readNetConfig: 在writeEnabledNetInfo將timeout寫入dhclient config中;在wait_for_iface_activation內會根據timeout做retry。 再來從log與code可以得知,它讀取的檔案是answer file而不是boot command line。因此我接下來的測試,就是在answer file的network command上加入dhcptimeout: network --onboot = yes --bootproto =dhcp --ipv6 =auto --device =eth1 --...

第一次寫MIB就上手

SNMP(Simple Network Management Protocol)是用來管理網路設備的一種Protocol,我對它的認識也是從工作接觸開始。雖說是管理網路設備,但是主機、電源供應器、RAID等也都可以透過它來做管理。如果你做了一個應用程式,當然所有的操作也都可以透過SNMP來完成,不過可能會很痛苦。前陣子遇到一個學弟,它告訴我說:「我可能不會想寫程式。」為什麼? 因為這是他痛苦的根源。 在這篇文章中,不是要告訴你SNMP是什麼,會看這篇文章的大哥們,應該已經對SNMP有些認識了。 是的!主題是MIB(Management information base)! 對於一個3th-party的SNMP oid,有MIB可以幫助你去了解它所提供的資訊是什麼,且可以對它做什麼操作。最近我運氣很好剛好做到關於修改MIB的工作,也讓我順便了解一下它的語法,接下來我要交給大家MIB的基礎認識。 smidump 我並非使用什麼高強的Editor去編寫MIB,我僅透過Nodepad++編輯和smidump編譯而已。smidump是Kay教我使用的一個將MIB module轉成樹狀結構或oid列表的工具,唯一的缺點是不會告訴你哪一行打錯。當然有錢直接買編輯樹狀結構的工具就可以不需要了解語法了! 安裝 在Ubuntu上可先輸入smidump確認是否安裝,如果沒安裝可透過apt-get install libsmi2ldbl安裝。(CentOS可以透過yum install libsmi) root@tonylin:~/multi-boot-server# smidump The program 'smidump' is currently not installed. You can install it by typing: apt-get install libsmi2ldbl 使用 透過下面兩行指令,就可以將mib file產生出對應的tree與oid列表的檔案。也可以透過這個結果確認MIB是不是你想要的。 smidump -f tree example1.mib > xtree.txt smidump -f identifiers example1.mib > xiden.txt 如果有參考其它檔案要加上p的參數: smidum...