最近我在脑筐上进行了测试并得到了不错的结果(类似4.5,硕士学位)。我只知道1个问题的答案(其余的我确定或至少我认为我知道正确答案:))。问题是:
以下哪一项不是创建自定义例外的原因?
选择1
插入强力标签以供日后检查
选择2
强烈地键入特定例外的目的
选择3
允许远程序列化
选择4
在创建例外时处理常见步骤
选择5
添加自定义数据传播的自定义属性
我回答“4” - 在创建例外时处理常见步骤。您认为哪一个是正确的?
答案 0 :(得分:4)
选择3.基本例外或者已经支持远程处理,否则你从中派生它将不会添加远程处理。
Marc在评论中提到的“例外”如下:我认为这不是测试作者的想法:
在WCF服务中,您可以允许未处理的异常传播出服务。 WCF会将其转换为SOAP Fault,它可能包含也可能不包含未处理异常的详细信息,具体取决于配置。
更好的方法是识别某些异常集并将其故意转换为SOAP Faults。例如,对数据库实体进行操作的服务可能会发现有时无法找到实体;有时尝试添加新实体会导致重复;有时更新尝试会导致无效状态。此类服务可能会决定公开NotFoundFault
,DuplicateItemFault
和InvalidStateFault
。
该服务将三个故障定义为数据合同以定义其内容:
[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)
最后,您可以从DAL中包装一个异常,以便WCF返回特定的错误:
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异常类都是可序列化的。因此,序列化的能力不是创建自定义异常的借口,因为基类应该已经可序列化。
答案 1 :(得分:1)
我实际上同意4是错误的:在创建异常时处理常见步骤。
异常不应该在创建时执行“步骤”,而是通知系统已经创建了当前类(以及可能的模块)不知道如何寻址的异常情况。
如果正确执行某个函数需要执行公共步骤,那么该函数应该包含在代码本身中,而不是分成异常。
答案 2 :(得分:0)
在使用WCF服务时,我们必须为序列化创建自定义例外。所以3不能是正确的答案。