none
例外の再Throwについて RRS feed

  • 質問

  • 例外の再Throwについて質問です。

    VB.NET(3.5)にてコンソールAP(バッチ)を作成していますが、
    下記のサンプルコード①~②について質問があります。

      ●①の例外の再Throwについて
        インターネットでのサンプルコード等を見ても再Throwしている例が多いのですが、
        呼び出しの最上位クラスでのCatchが保証されれば、不要な気がします。
        中間でTry-Catchを行うメリット/行わないデメリットがあればご教授願います。
      ●②でのTry-Catchについえt
        上記①と同じく、最上位クラスでのCatchが保証される前提ですが、
        システム例外の際のex.Messageを書き換えなければTry-Catchを行う意味がない気がするのですが、どうなんでしょうか??

    詳しい方がいらっしゃいましたら、ご教授願います。

    ====以下サンプルコード====
    ###最上位クラス(実行ファイル)###
    Public Sub MainExcuter
        Try
            '業務処理を呼び出す
            Call BusinessLogic
        Catch custException
            'ユーザ例外が発生した場合の処理
        Catch sysException
            'システム例外が発生した場合の処理
        End Try
    End Sub

    ####業務処理呼び出しクラス###
    Public Sub BusinessLogicLib
        Try
            '業務処理Aを実行する
             Call LogicA
        Catch ex As Exception
            '例外の再Throw(空のthrow)  … ★★★①★★★
            Throw
        End Try
    End Sub

    ###業務処理A実装クラス###
    Public Sub LogicA
        Try   … ★★★②★★★
            '処理Aのコード
            '業務エラーの場合はCustom例外を生成しThrowする。
        Catch ex As Exception
            'システム例外の場合は処理停止
            '必要に応じてex.Messageを書き換える 
        End Try
    End Sub

    2010年10月5日 11:24

回答

  •   ●①の例外の再Throwについて
        インターネットでのサンプルコード等を見ても再Throwしている例が多いのですが、
        呼び出しの最上位クラスでのCatchが保証されれば、不要な気がします。
        中間でTry-Catchを行うメリット/行わないデメリットがあればご教授願います。
     

    私も不要だと思います。業務エラーであればLogicA内で処理されるべきでしょうし、システム例外であれば一旦catchして再throwすることに意味が無いと思います。

      ●②でのTry-Catchについえt
        上記①と同じく、最上位クラスでのCatchが保証される前提ですが、
        システム例外の際のex.Messageを書き換えなければTry-Catchを行う意味がない気がするのですが、どうなんでしょうか??

    私もそう思います。システム例外は、Windowsフォームの場合は最上位のApplication.ThreadExceptionイベントハンドラで処理すれば良いと思います。
    以下のシリーズが詳しいので、まだ読まれていないのであれば一度読まれることをお勧めします。

    .NETの例外処理 Part.1
    http://blogs.msdn.com/b/nakama/archive/2008/12/29/net-part-1.aspx


    ★良い回答には回答済みマークを付けよう! わんくま同盟 MVP - Visual C# http://d.hatena.ne.jp/trapemiya/
    • 回答としてマーク TakaNN 2010年10月8日 7:39
    2010年10月5日 13:43
    モデレータ

すべての返信

  •   ●①の例外の再Throwについて
        インターネットでのサンプルコード等を見ても再Throwしている例が多いのですが、
        呼び出しの最上位クラスでのCatchが保証されれば、不要な気がします。
        中間でTry-Catchを行うメリット/行わないデメリットがあればご教授願います。
     

    私も不要だと思います。業務エラーであればLogicA内で処理されるべきでしょうし、システム例外であれば一旦catchして再throwすることに意味が無いと思います。

      ●②でのTry-Catchについえt
        上記①と同じく、最上位クラスでのCatchが保証される前提ですが、
        システム例外の際のex.Messageを書き換えなければTry-Catchを行う意味がない気がするのですが、どうなんでしょうか??

    私もそう思います。システム例外は、Windowsフォームの場合は最上位のApplication.ThreadExceptionイベントハンドラで処理すれば良いと思います。
    以下のシリーズが詳しいので、まだ読まれていないのであれば一度読まれることをお勧めします。

    .NETの例外処理 Part.1
    http://blogs.msdn.com/b/nakama/archive/2008/12/29/net-part-1.aspx


    ★良い回答には回答済みマークを付けよう! わんくま同盟 MVP - Visual C# http://d.hatena.ne.jp/trapemiya/
    • 回答としてマーク TakaNN 2010年10月8日 7:39
    2010年10月5日 13:43
    モデレータ
  • 「throw のみしか書いていない catch ブロック」の話なのか、「最後が throw で終わっている catch ブロック」の話なのかで、回答が大きくかわるきがします。

    前者については、trapemiya さんも書かれていますが不要だと思います。後者については、状態管理やリソース管理などの簡略化ために利用されることが多いと思います。たとえば、C# ですが、下のような内容は厳密には前者の不要な try-catch に相当しますが、「x をローカル変数にして、すべての return の手前に this.x = x を書く」ことにくらべると、簡素でわかりやすいと思います。
    # 徹底的にやるなら、try ブロックの中身を精査して try をなくすべきでしょうけどね

    void Method1()
    {
     this.x = new ...();
     try
     {
       ....
     }
     catch
     {
       this.x = null;
       throw;
     }
    }
    
    2010年10月6日 4:08
  • 返信が遅れて申し訳ありません。
    不要なThrow(中身のないThrow)は記述しない方針としたいと思います。
    ご回答ありがとうございました。

    2010年10月8日 7:50