1.異常處理的好處在絕大多數的情況下都是大於壞處,請盡量使用異常處理.
2.如果要針對單獨一種異常進行了try...catch處理後,最好外面再要外包一層try...catch去捕捉未知的異常(或者用乙個try,多個catch,而最後乙個catch就是用來catch未知異常),因為你永遠都不不能保證你的程式在**丟擲何種異常,正如引用文章那個中所說的outofmemoryexcetpion等異常是很常見的,想象一下有過萬行的資料轉化成excel報告這樣的情景,丟擲這個異常就不足為奇了,因為我就遇到過.^_^
3.try...catch要包裝盡量少的**嗎? 顯然,沒有發生異常的時候,基本是沒有什麼效能損失的,決定要不要這樣做,其實得看情景的,例如乙個很簡單可能發生除零錯誤的**塊,就可以很明確的只try...catch這一段,讓人更明確這裡到底會出什麼問題,同時告訴人家你已經對預計中的問題都做了處理了.但這種完美的情況基本上都是不存在的,所以說盡量try更多的**,catch更多的異常顯得更重要,因為一些已經知道的異常,為什麼還要你try呢?何不自己就靜悄悄的處理掉呢?是吧 ^_^
4.底層的框架類庫盡量少用try...catch嗎? 底層的框架類庫通常比較通用,效能的要求也比較高,所以只在總介面中使用try...catch?這也許是很多人的一些誤解,他們或者會認為有了總介面中做了異常捕捉就可以萬事大吉,因為異常是會一層一層網上丟擲來的,所以有異常可定能捕捉到.但實際中如果這樣操作會出現很多問題.因為這樣很不利於程式的排錯,特別是在一些時間比較緊要求並行開發(類庫和業務**同時進行開發)的專案中,到了**會師那一刻,**有bug,排錯就很困難,因為catch到已經是穿過幾個時空後的原始人,都不知道他是來自那個世紀的^_^,所以其實底層更需要try...catch.
5.catch中不要包含業務邏輯! 有些朋友喜歡在異常處理模組中把業務包含進去,但這樣其實有很大的隱患的. 我曾經看到過這樣的乙個例子,有個業務邏輯是要判斷使用者是否設定了某個時間,然後用這個時間進行其他處理,這裡那位哥們使用乙個省勁的方法,就是先把取出來的值做時間轉換,能轉就是有定義,不能轉丟擲異常就判斷使用者沒有定義這個時間,這樣做初初看上去好像問題也不大,但是日後如果客戶要投下業務變動的原子彈,後果是如何,大家想像一下就知道,這裡引用句經典話,"誰用誰知道啊" ^_^
6.盡量"throw;",不要"throw e;". 這兩者有什麼區別呢,如果使用"throw e;"只是單純把捕捉到的異常丟擲來,其實還有一些存在與堆疊中的資訊沒有被丟擲來,所以throw出來的東西是經過過濾的,如果大家是要向上一層進行throw,就要來得徹底點,不然又可能會給排錯加上一層不該有的迷霧的哦 ^_^
7.catch中如果要寫log,請把當前stacktrace也要拉進來. 因為把stacktrace記錄下來,可以獲取一些對排除異常很有幫助的資訊,例如引發這個異常的呼叫的事件和函式列表等,想象乙個經過多次throw才catch的異常,有這個瓜藤,就不怕摸不著瓜啦,是吧 o(∩_∩)o
關於一些空指標異常的一些問題
listschedultcustomproductids new arraylist if schedultcustomproductids null 這樣是不能阻擋getbyids 方法的執行的 size 0和null是不同的,new完以後,是會給他分配記憶體的,是size 0,因為給他分記憶體了...
CLOB處理的一些問題
1 clob超過2的15次方時,隱式字元轉換會失效,導致無法拼接數字至clob 我用如下指令碼做了測試,當 clob 超過32767 的時候拼接數字就是出現問題 字元轉換失效 需要對數字進行轉換才能拼接成功 32767 應該是clob 乙個儲存塊的大小吧.具體原因還需要查閱 clob 相關文件 有更...
關於面試的一些問題
面試過程中，面試官會向應聘者發問，而應聘者的回答將成為面試官考慮是否接受他的重要依據。對應聘者而言，了解這些問題背後的 貓膩 至關重要。本文對面試中經常出現的一些典型問題進行了整理，並給出相應的回答思路和參 讀者無需過分關注分析的細節，關鍵是要從這些分析中 悟 出面試的規律及回答問題的思維方式，達到...