0

私が働いている会社で開発しているソフトウェアには、常に連絡を取り合っている人が開発したサードパーティのライブラリを使用しています。彼のコードは C++ で書かれており、プロジェクトでは C# を使用しています。

通常、彼のライブラリ関数はエラー コードを返します。さまざまな範囲のエラー コードをカバーするために、さまざまな例外クラスを用意することにしました。たとえば、パラメーター処理エラーの例外クラスが 1 つ、メイン操作エラーの例外クラスが 1 つ、入力値エラーの例外クラスが 1 つなどです。

彼はそれは良い考えではないと考えており、すべてのエラーをキャッチし、XML ファイルからエラー コードを取得してユーザーに問題を出力するライブラリに 1 つの例外クラスを使用することを提案しています。彼は、複数の例外クラスを書くのは無意味だと考えています。また、彼は、ライブラリの異なるバージョンでエラー コードが同じになるとは約束できないとも言っています。

次の理由から、複数の例外クラスを用意することをお勧めします。

  1. 問題を別の方法で処理する必要があるさまざまな状況があるかもしれません。パラメーターの例外が発生した場合は、エラーを出力するだけでなく、他のことを行うこともできます。しかし、彼は自分のライブラリがすべてを処理していると考えており、操作を停止してエラーを出力する必要があります。また、エラー メッセージを表示する以外に、別の方法で処理する必要があるケースの具体的な例はあまり思いつきません。しかし、私はそれが必要かもしれないと感じており、YAGNI の原則に違反しているのではないかと心配しています。
  2. 彼が間違っていることが判明し、さまざまなケースで異なる方法で処理する必要がある場合は、条件付きコードを導入する必要があると思います (エラーが A の場合はこれを行い、B の場合はそれを行います)。そして扱いづらくなります。

さまざまな種類の例外を異なる方法で処理できるようにプログラムを開発する方がよいと思います。しかし、その人は私よりもはるかに経験が豊富で、会社での信頼性も高く (私は新しいインターンです)、私はソフトウェア開発にかなり慣れていないので、おそらく彼は正しいと思います。見栄えが良く、YAGNI の原則に違反しているという理由で余分なコードを追加する。

1 つまたは複数のクラスを使用する必要があると思いますか? また、複数の例外クラスを使用する必要があると考える場合、その理由は何ですか?

4

3 に答える 3

1

エラー コードがバージョンごとに変わる可能性がある場合、作業量 (または作業不足) によって、ある時点で何らかの方法でこれらを再マッピングする必要がなくなります。コード (またはコード範囲) の例外がある場合、エラー コードが変更されたときに、ない場合よりもはるかに多くの作業が必要になることはほとんどありません (スローされる例外を再配置するのと同じように)専用のクラスがない場合は、1 つの例外としてメッセージを揺らさなければなりません)。

さらに、一般的な慣行では、.NET の慣例により、BCL が提供する例外では適切にカバーされない特定の例外に対して専用の例外クラスを作成する必要があります (抽象化のみを目的とした例外の使用は除きます)。

一部の Microsoft 入力については、次のことを考慮してください。

アプリケーションとライブラリは、リターン コードを使用してエラーを伝えるべきではありません。

そしてこれ：

カスタム例外タイプを作成する代わりに、System 名前空間に存在する既存の例外をスローすることを検討してください。

ただし、例外設計ガイドラインに従って、

[予定] は、必要に応じて既存の例外を確実に使用し、ライブラリに価値を追加する新しい例外を作成するのに役立ちます。

あなたの銃に固執します。

于 2013-01-28T15:24:40.820 に答える
0

必ず複数の例外クラスを使用する必要があります。ただし、名前空間にはや friendsSystemなど、すでに作成されている組み込みクラスがたくさんあることに注意してください。ArgumentNull

複数の例外が使用されていないケースを確認したい場合は、COM 相互運用をご覧ください。これは、一般的な例外がスローされ、その理由が単一の整数によって正当化される暗い場所HRESULTです。私を信じてください、あなたはそれを再現したくありません.

ただし、特定の例外をキャッチしたい場合など、非常に具体的な使用例があります。すなわち

try
{
  lib.OpenFile(mypath);
}catch(FileNotFoundException e)
{
 //handle gracefully and possibly "ignore" this error 
}

ここでは、ファイルが見つからない場合に別のアクションを実行します。ただし、が null でOpenFileあるために例外をスローする場合は、mypathおそらくこの例外をバブルアップさせてエラーをスローする必要があります。（少なくとも、ログに記録できるようにするためなど）。単一の例外クラスでは、これはより苦痛になります

catch(MyException e)
{
  if(e.Reason=10)
  {
  }else{
    throw; //rethrow exception(which makes debugging more difficult)
  }
}
于 2013-01-28T15:29:08.050 に答える
0

あなたが正しい。さまざまな種類のエラー (さまざまなエラー コード) に対して、いくつかの例外クラスを使用することをお勧めします。例外はエラー コードの後継者なので、例外を使用することをお勧めします。そして、男が提供しているアプローチは、1 つの例外クラスでラップされたエラー コードを使用することです。

彼の Number を持つ SqlException が頭に浮かびます。エラー コードをチェックして、さまざまな種類のエラーをキャッチするのは地獄です。

于 2013-01-28T15:23:24.943 に答える