3

私は API を設計しています (初めて)。これは非常に公開されるものです (無料のオンライン サービス用)。

InsertResult失敗または成功したとき (つまり、行数)、エラー メッセージなどのプロパティを持つことができる構造を返すことを検討しています。もう 1 つの方法は、API 挿入メソッドから例外をスローすることです。これは一種の「一般的でオープンな」質問であることは承知していますが、API にとってよりクリーンで洗練されていると見なされるものは何ですか?

シナリオ

API は DLL です (4 つまたは 5 つの異なるソースから Web サービスを内部的に呼び出して消費し、地理位置情報などに応じて、どのサービスと対話するかを決定します)。C# と Mono を使用して構築されています。使用シナリオには、デスクトップ、モバイル、および Web クライアントからのライブラリとしての API が含まれます。それは確かに問題です.オフラインのユースケースを想定してください.Webクライアントからは単純に起こりませんが、モバイルまたはデスクトップからは（モバイルからより頻繁に）それから何をすべきでしょうか? オフラインになったときにモバイルアプリからモックを保存するための挿入呼び出しを管理する方法。または、別の (サーバー関連の) エラーが発生した場合。

4

5 に答える 5

2

通常、ユーザーが無効なことをしようとした場合は、例外をスローする必要があります。ただし、例外が発生する前に、ユーザーが例外をスローする可能性のある条件を適切にチェックできるコード パスも提供する必要があります。重要な場合 (おそらくパフォーマンス上の理由から)、無効な挿入を安全に処理し、成功を示すためにTryInsert単純に有効を返すメソッドを含めることができます。bool

これは、純粋な C# API だけでなく、サービス API にも当てはまります。

于 2013-03-27T21:27:35.657 に答える
2

例外のスローは、C#/.NET でエラーや予期しない状況を処理するより自然な方法です。さらに、.NET では、独自の例外を定義したり、既存の例外の 1 つを使用したりすることができます。
さらに、ブロックのようなものを提供することでfinally{}、何か問題が発生したときに非常にスムーズに進めることができます。
戻り値のチェックはエラーが発生しやすく、ユーザーが戻り値に適切に反応しない場合、プロセスが不安定になる可能性があります。通常、未処理の例外はプロセスを停止するため、ユーザーはバックグラウンドを確認する必要があります。でも、それは私の意見です。

MSDNでは、たとえば、パラメーターが間違っていて、間違った入力で続行できない場合、例外をスローするのはかなりの理由であると彼らは言います。

于 2013-03-27T21:27:47.940 に答える
2

質問は「一般的でオープン」であるため、Google、Amazon などのほとんどの使用されている Web サービスを考慮すると、それらはすべて、可能な限り正確な詳細を提供するという原則に従っていると思います。

例外をトローするだけでは、API のユーザーがさらにバグを起こす可能性があります。

要約すると、よく知られているエラー コードを定義し、同じ情報をクライアント/コンシューマに渡して、呼び出しの何が問題なのか、またはそれを修正するために何をすべきかを簡単に把握できるようにすることを常にお勧めします。何らかの理由であなたのAPIが特定のエンコーディングのみを受け入れると、ユーザーはそれに不満を感じるでしょう。

于 2013-03-27T21:29:19.397 に答える
2

詳細なエラーを返すことをお勧めします。Web サービスを利用するために使用しているため、すべての人が同じテクノロジを使用して対話するわけではありません。フレームワークを作成している場合は、開発者が同じテクノロジを使用してそれを使用するため、例外を使用することをお勧めします。これは、フレームワーク レベルで例外がより役立つ場所です。

更新 (問題の API は実際にはフレームワークです): フレーム ワークの使用について話しているので、クライアントは DLL を参照する必要があり、フレームワーク例外の可能性を認識しているため、例外をスローする必要があります。ライブラリを使用するには、CLR 準拠の言語である必要があるため、同じ概念、クラス、例外などを持つ必要があります...

于 2013-03-27T21:36:39.583 に答える
0

API の場合、例外は常に優れています。API コンシューマーは、catch ブロックを使用してさまざまな例外に対処できます。エラー メッセージとエラー コードを使用する場合は、API コンシューマーに If ステートメントを記述するように求めています。以下のスニペットは、エラーをチェックする If 条件があるものよりも常にクリーンです。

したがって、API コンシューマーの観点からは、API が例外をスローすることが常にクリーンです。

try
{
    yourAPIClass.YourMethod();
}
catch(YourException1 ex)
{
   action1();

}
catch(YourException2 ex)
{
   action1();

}

例外を記述してスローするための適切なガイドラインは次の とおりですhttp://blogs.msdn.com/b/kcwalina/archive/2005/03/16/396787.aspx

于 2013-03-27T21:30:59.793 に答える