[Java]
SuccesException
投稿者からのアピールポイント
戻値は必ず投げて返すこと。
かつてこんな規約が推奨されてた時期なかったですかね… Javaって面倒なんだなぁって思った記憶だけが心の隅に残っててるんですが web上にもそんな痕跡は何処にも無いからただの記憶違いかなぁ・・・ ここではまとめてますけど、細かく処理ごとに例外を分けて投げるようになってた気もします。
public class Action{
public static void process(int arg) throws OrgnalException
{
OrgnalException e = new OrgnalException();
e.hasError = false;
if(arg < 0)
{
e.hasError = true;
e.muinusError = true;
}
//・・・略
throw e;
}
public static void main(String[] args) {
try {
process(Integer.parseInt(args[0]));
} catch (NumberFormatException e) {
e.printStackTrace();
} catch (OrgnalException e) {
if(!e.hasError)
{
//略
}
else if(e.muinusError)
{
//略
}
//略
}
}
}
コメント(15)
えーと、処理の最後に例外を投げて…？？？ Javaはあんまし詳しくないけど変なのはわかった
あまり意識されないが、Javaで例外を作るってのは非常に処理負荷が高い。
記録にないほど昔ってことは、VMの起動が重すぎてappletが全然流行らず、PCのスペックも低くて開発もままならなかった、あの時代でしょう。例外を量産するなんざ、それこそ論外だったんじゃないかな。
オーバーライドしたメソッドによって、メソッドの戻り値を変更できない（たとえ安全でも）というJavaの言語仕様がある。たとえば、戻り値がMapのメソッドを、引数と名前が同じ戻り値HashMapのメソッドでオーバーライドすることができない。これって変じゃね？という議論が昔はあった。JSRの番号は覚えてないけど。
ところで、送出例外の宣言においては、上位のメソッドがIOExceptionを送出するようになっていれば、下位のメソッドのthrows句にはFileNotFoundExceptionを宣言できる。そこで、上述の問題を解決するために戻り値の代わりに例外を使用するという半ば冗談のソリューションが提案されたことがあった。
たぶんそれのことじゃないかな。
Javaで例外オブジェクトを作るのが特段重いってのは、あんまり聞いたことがないな。C++のtry / catchは、実質setjmp, longjmpでスタックの保存・復旧を伴う分重いってのがかつて言われていたのを記憶しているけど。
5 長年の謎が解けた気がします。その辺の話をまともに受けて先走って作った仕様だったのかも。
例外生成が重い件。古い記事だと、この辺
http://www.ibm.com/developerworks/jp/java/library/j-perf07303/
実践してみたよ、的な記事もいくつか発見
http://www.limy.org/program/java/performance_tuning1.html
http://blob.geishatokyo.com/archives/134019
最近は改善されてるかも知れないので、あくまでご参考まで。
言葉が足りませんでした。Javaで例外オブジェクトを作るのが＜他の言語に比較して＞特段重いってのは、あんまり聞いたことがないというのをいいたかったのでした。通常のオブジェクトに比較すれば、はるかに重いのはおっしゃるとおりです。
http://blob.geishatokyo.com/archives/134019
は参考になりますね。ありがとうございます。
ちなみに今はできますね。 戻り値のオーバーライド。(Java SE5以降) https://blogs.oracle.com/darcy/entry/covariant_interface_hierarchies
恥ずかしながら、今まで気がついてませんでした。
そもそもの話、多言語と比較して何か嬉しかったんだっけ。
他言語と比較すればまだ軽い方なんだから、例外を量産したって怒られないぜ、てことかいな。
"Javaだと例外生成が重い"というふうに他言語と比較して例外生成が重いと聞こえるようなことをだれかが言っていたからじゃないですかね。よく覚えてないけど。
この発想はなかったし、あってはいけなかった