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海