2009-05-09 17 views
-1

最近、私は脳卒中でテストを受け、悪い結果は得られませんでした(4.5、修士号など)。私は1つの質問(私が確信していた、または少なくとも私は正しい答えを知っていると思った:)で答えを知らなかった)。質問は次のとおりです。カスタム例外を作成する理由はありませんか?

カスタム例外を作成する理由はありません。へのリモートシリアル化
チョイス4
を可能にするために、特定の例外
チョイス3
の目的を強く型と後で検査するため
選択肢2
を強いラベルを挿入する

チョイス1
例外が作成されたときの一般的な手順を処理します。
選択肢5
カスタムデータ伝達のカスタムプロパティを追加するには

私は「4」と回答しました - 例外が作成されたときの一般的な手順を処理します。どちらが正しいと思いますか?

+0

PS。テストは "C#2.0 Fundamentals"でしたので、WCFの面は考慮できません。 – nightcoder

答えて

4

選択肢3.基本例外はすでにリモート処理をサポートしているか、それ以外の場合はにはリモーティングを追加しません。


コメント内の「例外」マークのコメントは次のとおりです。テスト作成者が念頭に置いたものではないと思います。

WCFサービスでは、未処理の例外がサービスから伝達されるようにすることができます。 WCFはSOAPフォールトに変換します。SOAPフォールトには、構成に応じて未処理の例外の詳細が含まれる場合と含まれない場合があります。

特定の例外セットを認識し、意図的にSOAPフォールトに変換する方がよいでしょう。たとえば、データベースエンティティで動作するサービスでは、エンティティが見つからないことがあります。新しいエンティティを追加しようとすると重複が発生することがあります。更新の試みによって無効な状態が生じることがありました。このようなサービスでは、NotFoundFault,DuplicateItemFault、およびInvalidStateFaultが公開される可能性があります。

サービスは、その内容を定義するデータコントラクトとして3つの障害を定義します

[DataContract] 
public class FaultBase { 
    [DataMember] 
    public string ErrorMessage {get;set;} 
} 

[DataContract] 
public class NotFoundFault : FaultBase { 
    [DataMember] 
    public int EntityId {get;set;} 
} 

[DataContract] 
public class DuplicateItemFault : FaultBase { 
    [DataMember] 
    public int EntityId {get;set} 
} 

[DataContract] 
public class InvalidStateFault : FaultBase { 
} 

あなたは、特定の操作は、このような障害を返すことができることを示すことになる:

[OperationContract] 
[FaultContract(typeof(NotFoundFault))] 
public Entity GetEntityById(int id) 

最後に、あなたが包むかもしれません代わりにWCFが特定の障害を返すようなDALの例外:

try { 
     return DAL.GetEntity<Entity>(id); 
    } 
    catch (DAL.NoSuchEntityException ex) 
    { 
     throw new FaultException<NotFoundFault>(
      new NotFoundFault {EntityId = ex.Id, ErrorMessage = "Can't find entity"}); 
    } 

テストデベロッパーは、別のAppDomainへのリモート処理のために例外をシリアル化するために特別な処理が必要であると考えるようにしていると思います。提供された.NET例外クラスがすべて直列化可能であるため、カスタム例外が適切に実装されていれば、これは当てはまりません。したがって、シリアライズする能力は、基本クラスがすでにシリアライズ可能である必要があるため、カスタム例外を作成する言い訳ではありません。

+0

はい、多分、私はすでに質問を書く前にそれについて考えました。 – nightcoder

+0

私も3と投票しました!それ以外のものはすべて、カスタム例外を作成する理由です。 –

+0

Re 3 - .NETの "remoting"にも当てはまるかもしれませんが、WCF 3 *は例外を "fault"(特別なクラス例外)を返します。 –

1

私は実際には4が間違っていることに同意します:例外が作成されたときに一般的な手順を処理する。

例外は、作成時に「ステップ」を実行することは想定されておらず、現在のクラス(および場合によってはモジュール)が対処方法を知らない例外的な状況が作成されたことをシステムに通知します。

関数の適切な実行に共通のステップを実行する必要がある場合は、その機能をコード自体に組み込んで例外に分割しないでください。

+0

私はそれを購入します... –

+0

クリーンアップアクションを「例外が作成される一般的な手順」と考えると、「作成済み」とは文字通り考えないと意味があります。 Brainbenchテストでは、誤解を招くような文言があることがあります。 –

0

WCFサービスを使用しているうちに、シリアライズのカスタム例外を作成する必要がありました。だから3は正解になることはできません。

+0

PS。テストは "C#2.0 Fundamentals"でしたので、WCFの面は考慮できません。 – nightcoder

+0

Ok ...ウェブサービスにも同じことが当てはまります –

関連する問題