2

ファイルを転送し、リモートサーバーで操作するためのインターフェイスを設計しています。混乱は、インターフェイスのメソッドが呼び出し元のコードを返す必要があるかどうかです。想定される利点は、呼び出し元が例外をキャッチする必要がないことです。

または、正しい方法は、ボイドを返し、失敗条件で例外をスローすることです??? もしそうなら、例外はカスタムであるべきですか？または言語によって定義されたプリミティブなもの (この場合は C#) ??

 //Remote transfer interface 1
 enum codes { SUCCESS, FAIL, HOSTUNREACHABLE, so-on and so forth }
 codes init(String host, int port);
 codes transferFile(String filepath, String remotename);
 codes deleteRemote(String remotePath);

転送する 2 番目のタイプの iterface 

 //Remote transfer interface 2
 //Following methods throw exceptions when they occur, catched by caller..
 void init(String host, int port);
 void transferFile(String filepath, String remotename);
 void deleteRemote(String remotePath);

どの方法が最適で、その理由を教えていただけますか?

4

2 に答える 2

0

CLR で API を使用している場合、API を使用するすべての言語で例外を処理できるため、それらを使用する必要があります。

エラー処理前の例外、戻りコードのチェックは簡単に忘れられ、エラーが発生すると問題がコードの後半に現れる可能性があります。また、エラーが発生したときとまったく同じ前提条件をデバッグして復元することなしに、いつ問題が発生したかを知る方法がない場合があります。例外を使用すると、エラーケースを処理するのを忘れた場合に正確なエラー情報を取得し、プログラムフローの後半ではなく、エラーが発生したときにエラーを処理するように強制できます。

于 2012-11-06T10:20:03.080 に答える
0

ここに絶対的な最善の解決策はありません。すべては API の設計に依存します。コンパクトな、または「自己完結型」の API を作成する場合は、そのインターフェイスの実装内でIO 例外を処理することを考えることができます。

内部で処理しない例外があり、その呼び出し元がそれらを何らかの方法で処理することを望むという事実を考慮してください。

このタイプの実装は、実際にすべての「もの」がどのように機能するかの詳細を隠し、標準化されたコードを介して呼び出し元と「対話」するため、優れています。

talking-ring例:独自のカスタム プロトコルを使用して、PLC コントローラー用の通信レイヤーを作成しているとします。呼び出し元は、プロトコルがどのように機能するかを気にする必要はありませんが (プログラムの実行中に発生する可能性のある予想外の例外を処理するため)、関数を呼び出して、成功したか失敗したかの事実に関する情報を取得するだけです。

于 2012-11-06T10:11:36.217 に答える