無差別に技術をついばむ鳥

情報処理技術全般を気まぐれに研究するブログです

C++/CLIをつつく25−例外処理1。エラー処理はほうれんそうが大事。

前回で例外処理の構文は覚えたと思う。だけど、例外処理を使いこなすのは文法だけ覚えるだけでは不十分で、有効な使い方を学ぶ必要があるんだ。といっても、難解な理屈を書かないからリラックスして読んでね。
例外処理の使い方の基本は勿論エラー処理ピヨ。 エラーに対処するための機能として存在するんだ。だけど、例外処理というものがどうしてエラー処理に必要なのかわからないと思うからそこから説明するピヨ。
例外処理が無い時代のエラー処理は、統一性が無い混沌とした状態だったんだ。具体的に書くと、 関数がエラーを起こした場合マイナス値を返すエラーの内容を表す値を返す、 C言語のように専用の関数でチェックする・・・など色々あったんだ。 これが何故悪いのかというと、統一性が無いので関数ごとにエラー処理の方法を調べなくてはならない、注意がそれて本来の目的から遠ざかる、エラーチェックを簡単に忘れられる、といった多くの問題が生じるからなんだ。古い言葉でボクもあまり聞いたこと無いけど、報告・連絡・相談・のほうれんそうは大事だということなんだね。これが如何に効率が悪く間違いの元なのかは現実世界に例えて考えてみよう。


その会社は業務の連絡方法がバラバラです。ある作業では「問題があったらさ〜〜〜んと馬鹿になって叫んでくれ。」と規定されている。さらに、またある作業では「エラーチェック班が居るからその部署に書類を持っていってくれ。」と規定されている。それだけならまだしも、酷い業務だと「問題が無数に発生する恐れがあるから、問題対応表を見て数値で連絡してくれ。」となっています。
もちろんこの状態では新入社員は混乱するばかりです。「先輩。この作業は馬鹿になったらいいんですか?エラー処理班に書類を持っていくのですか?それとも、問題対応表を調べて数値を部長に報告すればいいのですか?」・・・
一作業ごとに一々訊かれる後輩もたまったものではありません。大半の人はこういいます。「とにかく一作業ごとにググレ」・・・そうなってくれると、業務の大半は問題報告作業を調べることに時間が費やされる事になります。となれば、人間の習性上問題報告作業がおざなりになります。こんな状態で我が社は大丈夫なのでしょうか?
by とあるプログラマの人生相談


この例を読めば如何に非効率的かわかると思うピヨ。だからエラー処理方法を例外処理で統一するのがベストなのだぁ。また例外処理には統一性の他に、エラー情報が詳細になり、無視できないんだ。これほど便利な例外処理を使わない手は無いよね。
あれ?今気づいたけど、今回はコードを書いてないぞ。気持ち悪いからサンプルを書くピヨ。

//例外処理がある時
#include "stdafx.h"
using namespace System;

ref class Program
{
public:
    void Foo( int i ) {
        if ( i < 0 )
            throw gcnew ArgumentOutOfRangeException( "マイナスは許さん!" );
    }

    void Bar( String^ str ) {
        if ( str == nullptr )
            throw gcnew ArgumentNullException( "ちゃんと指定しろ!" );
        if ( str->Length == 0 )
            throw gcnew ArgumentOutOfRangeException( "1文字以上指定しろ!" );
    }
};

int main(array< System::String ^> ^args)
{
    Program^ foo = gcnew Program( );
    Int32 i = 10;
    String^ str = nullptr;
    //途中省略
    try {
        foo->Foo( i );
        foo->Bar( str );
    }
    catch ( ArgumentException^ e ) {
		Console::WriteLine( e->Message );
		Console::WriteLine( e->StackTrace );
    }
    return 0;
}
//読みやすい。はっはっはっは(^▽^)


//例外処理が無い時
#include "stdafx.h"
using namespace System;

ref class Program
{
public:
    void Foo( int i ) { }
    void Bar( String^ str ) { }
};

int main(array< System::String ^> ^args)
{
    Program^ foo = gcnew Program( );
    Int32 i = 10;
    String^ str = nullptr;
    //途中省略
    if( i < 0 ) {
	Console::WriteLine( "マイナスは許さん!" );
	return -1;
    }
    foo->Foo( i );
    if ( str == nullptr ) {
	Console::WriteLine( "ちゃんと指定しろ!" );
	return -1;
    }
    if ( str->Length == 0 ) {
        Console::WriteLine( "1文字以上指定しろ!" );
	return -1;
    }
    foo->Bar( str );
    return 0;
}
//読みづらい・・・σ(´〜`)ξ


これの短いサンプルプログラムを見ても可読性と情報量に差があるピヨ。
ということは実際の業務は数万行以上になるからどれだけ大変か想像できるよね。
思いを胸に今回は終わり。
別窓 | C++/CLI | コメント:7 | トラックバック:0 | ∧top | under∨
<<VB.NETをつつく25−例外処理1。エラー処理はほうれんそうが大事。 | 無差別に技術をついばむ鳥 | C#をつつく25−例外処理1。エラー処理はほうれんそうが大事。>>

この記事のコメント

処理の統一が例外の主目的はではないと思う。
「問題の発生部」と「問題への対処部」とをエレガントに繋ぐのが主目的で、処理の統一は二の次じゃないかしら。
2009-05-09 Sat 15:47 | URL | επιστημη #-[ 内容変更]
わざわざ、古い記事に指摘するとは、どういう意図ですか?
インドリを試してるの?
2009-05-09 Sat 16:29 | URL | n #-[ 内容変更]
> どういう意図ですか?

間違っていると思われるから。
2009-05-09 Sat 17:32 | URL | επιστημη #-[ 内容変更]
>間違っていると思われるから。

それは意図じゃなくて、指摘した理由でしょ。

過去の記事を見て粗を探し、わざわざ指摘した様に見えるんですけどね〜
2009-05-09 Sat 18:42 | URL | n #-[ 内容変更]
はい、「わざわざ」指摘しています。
技術的な指摘/コメントは大歓迎だそうですから。
2009-05-09 Sat 18:52 | URL | επιστημη #-[ 内容変更]
>はい、「わざわざ」指摘しています。

質問に答えてないですね。
で、意図は?
2009-05-09 Sat 18:54 | URL | n #-[ 内容変更]
意図(=目的)は「技術的な指摘」ですよ。
インドリさんの意見を伺い、間違っているのなら修正してもらいたいと。
2009-05-09 Sat 19:10 | URL | επιστημη #-[ 内容変更]
∧top | under∨

コメントの投稿

 

管理者だけに閲覧
 

この記事のトラックバック

∧top | under∨
| 無差別に技術をついばむ鳥 |