- PR -

try-catchもうひとつの使い方

1|2 次のページへ»
投稿者投稿内容
gocheong
会議室デビュー日: 2005/05/15
投稿数: 4
投稿日時: 2005-05-15 18:31
try-catchもうひとつの使い方
http://gocheong.riric.jp/Operate/try-catch.html

[ メッセージ編集済み 編集者: gocheong 編集日時 2005-05-15 19:31 ]
未記入
ぬし
会議室デビュー日: 2004/09/17
投稿数: 667
投稿日時: 2005-05-15 20:19
引用:
このやり方にすると必然的に厳密なプログラムをPGに書かせることができます。

「意識的にキャッチしないとフローを先に進めることができない」ということを意図したんだろうけど、うまく機能しないと思います。x()→y()→z() の順番でメソッドを呼びたいのなら、プログラマは次のように書くことができます。

コード:
    try {
        x();
    } catch(Exception e) {}

    try {
        y();
    } catch(Exception e) {}

    try {
        z();
    } catch(Exception e) {}

なので、必然的に厳密なプログラムを書くことを強制できているとは言えません。

引用:
もう一つ重要なのは、mainまで処理が停止することがありませんので、最後の処理「処理α１」は必ず実行されます。

「処理α１」を必ず実行したいのなら、finally を使えば済む話だと思います。

引用:
デバッグ作業をさらに効率よく行うことができます。(中略)この完了例外を採用すると、製作段階でかなりのバグを減らす効果が期待できます。

正常系処理フローが長くなればなるほど、ネストが深くなっていくんですよ？ コードの保守性が高いとはお世辞にも言えないと思いますが。括弧のズレなどでバグが発生するだろうことは十分に予想されます。

引用:
「throw」は文字通り「投げる」ですから、プログラマの心理上、投げるからには正確に投げ返えさなければと責任感を持たせることができるでしょう。

「return」は文字通り「戻す・返す」ですから、プログラマの心理上、返すからには正確に返さなければと責任感を持たせることができるでしょう。(ほんとかな？)

引用:
欠点はパフォーマンスが落ちるのではないかと思われることです。

パフォーマンス劣化など大した欠点ではないと思います。この試みの欠点は、「コードが煩雑になり保守性が低下すること」「正常系に例外を使用するという通常プログラマが考えない方法を用いていること(発想の共有が難しくなる)」だと思います。それに、正常系に例外を使うことを強制したとしても、結局、プログラマは return の代わりに throw を書くだけで何も変わらないのではないかと思います。

「投げる」と言えば「(無責任に)サジを投げる」って考える人もいるし。というか例外って自分で責任もって処理できない問題に直面したときに投げるものだと思うので、「サジを投げる」というのは、結構、的を射ているかもしれないな。
かつのり
ぬし
会議室デビュー日: 2004/03/18
投稿数: 2015
お住まい・勤務地: 札幌
投稿日時: 2005-05-15 20:42
例えば、
public void hoge() throws Exception
で定義されているメソッドであれば、
キャッチ忘れが直接バグの原因になりますね。
キャッチしなくてもコンパイルは可能になります。

未記入さんが仰るように、
例外を簡単に握りつぶすことも可能ですね。

実装方法も強制化されているようでは再利用性にも疑問が生じます。

＃私は、そんなコードが出てきたら即突き返します。。。
Kissinger
ぬし
会議室デビュー日: 2002/04/30
投稿数: 428
お住まい・勤務地: 愛知県
投稿日時: 2005-05-15 21:09
この方法のもう一つの問題は、例外を適切な呼び出し階層
で処理させることが難しくなることです。

初心者がよくやる誤りに、throwsで上位に伝播させるべき
例外を無闇に catchしてしまうことがありますが、
提案はこのような誤りを助長することになるでしょう。

新しい発明が gocheongさんのような逆転の発想から生まれ
ることも多いと思いますが、本件は残念ながら…。
K
大ベテラン
会議室デビュー日: 2004/04/07
投稿数: 174
投稿日時: 2005-05-16 00:35
今手元にないのであやふやですが、たしかEffectiveJavaにも例外処理機構を例外処理以外の
制御フローに使うのはやってはいけないことと書いてありましたね。
かつのり
ぬし
会議室デビュー日: 2004/03/18
投稿数: 2015
お住まい・勤務地: 札幌
投稿日時: 2005-05-16 00:53
私の場合、メソッドの宣言＝仕様と認識しています。
入力・出力・異常系が宣言によって示されます。

戻り値を返したい場合、どうするのでしょうか？
コード:
public class HogeException extends Exception{
    private Object obj;

    public HogeException(Object obj){
        this.obj = obj;
    }

    public Object getObject(){
        return obj;
    }
}


* 使い方 *
ライブラリ側
throw new HogeException(list);

実装側
コード:
List list = null;
try{
    hoge();
}catch(HogeException e){
    list = (List)e.getObject();
}catch(Exception e){
    例外処理;
}


合理性に欠けますよね。
tak3
ベテラン
会議室デビュー日: 2004/04/15
投稿数: 80
お住まい・勤務地: 菜の花・銀杏
投稿日時: 2005-05-16 00:53
Javaの格言の”例外の不適切な使い方”というのを思いだしました。
K
大ベテラン
会議室デビュー日: 2004/04/07
投稿数: 174
投稿日時: 2005-05-16 00:56
パフォーマンス結果で30倍遅くなったと出てますが、すべての制御フローをtry catchでおこなったら全体的にはかなりパフォーマンス劣化になりそうですね。
採用するメリットはなさそうです。
1|2 次のページへ»

スキルアップ／キャリアアップ（JOB@IT）