try/catch最慢是在negative result (exception occur)的時候。 因為會create exception的instance以致加重系統的stack call。 至少我相信在positive result的時候不會跟if/else的效率相差幾百倍這麼夸張。 （手邊沒java runtime也沒興趣去寫code try, 有興趣的大大可以 寫個測試程式post結果上來） OO的語言本來就是強調好maintain而不是performance, 真要跑得快的話，就啥都寫在public static void main 裡面。別做reflection, 別做serialization, 別做try catch, 甚至別create instance。 這時候寫個System.out.print的作業還能用, 叫你寫個framework出來看你怎麼maintain. (ps: 您若要這樣干的話，不如直接離開java的懷抱，直接投入組語的大家庭吧) 꼊真要做個堪用的系統出來，performance稍微犧牲一下是難免的。 系統跑得慢不要全部推給java啊，很多時候core的架構不良才是主要敗筆。 ※ 引述《[email protected] (n/a)》之銘言： > ※ 引述《tkcn (小安)》之銘言： > : 如果我沒記錯的話， > : ArrayIndexOutOfBoundsExecption 是繼承自 RuntimeException > : 而 RuntimeException 雖然也可以被 thorws, catch > : 但是並不建議這麼做 > : 所以以你的例子來說並不適當， > : 在這個例子應該要事先就避免才對 > : 題外話，以前曾經對你這個例子做過效率的測試 > : 使用例外處理的效率相對來講真是差到不行 > : (印象中相差了數百倍) > 一般可以用if else 做判斷的，我都不會想用try catch > 比如說數值範圍的限制，相等不相等之類的問題 > 也就是說，大部分可以事先處理的，我都會先處理好 > 而一些會造成程式無法繼續的錯誤 > 比如開啟檔案失敗，存取權限等等的問題 > 這些無法事先處理的問題(或者很麻煩，直接試看看會比較快) > 則用try catch 來處理 > 或者，我不想在函數內處理錯誤輸出，只是純脆想寫個通用的函數， > 不管在Console or Applet/Form 裡都不需要修改的函數， > 這樣子用try catch 就能把錯誤丟出函數，而不用馬上做出處理 > 最簡單的例子: > int div( int a, int b ) { return a / b; } > 我知道 b = 0 時是錯誤的，但直接在這函數裡做處理似乎是不合適的 > 因為 b = 0 時，函數根本無法繼續下去(除非重新給個 b )， > 而且不管 return 多少都不合適... > 嗯，說太多了。 -- 夫兵者不祥之器物或惡之故有道者不處君子居則貴左用兵則貴右兵者不祥之器非君子 之器不得已而用之恬淡為上勝而不美而美之者是樂殺人夫樂殺人者則不可得志於天下 矣吉事尚左凶事尚右偏將軍居左上將軍居右言以喪禮處之殺人之眾以哀悲泣之戰勝以 喪禮處之道常無名樸雖小天下莫能臣侯王若能守之萬物將自賓天地相合以降甘露民莫 之令而自均始制有名名亦既有夫亦將知止知止可以不殆譬道之在天下猶 tm.net.my海