标签: faults

我在WCF服务中有以下代码,根据某些情况抛出自定义错误.我得到一个"这个错误的创建者没有指定原因"例外.我究竟做错了什么？

//source code
if(!DidItPass)
{
    InvalidRoutingCodeFault fault = new InvalidRoutingCodeFault("Invalid Routing Code - No Approval Started");
    throw new FaultException<InvalidRoutingCodeFault>(fault);
}

//operation contract
[OperationContract]
[FaultContract(typeof(InvalidRoutingCodeFault))]
bool MyMethod();

//data contract
[DataContract(Namespace="http://myuri.org/Simple")]
public class InvalidRoutingCodeFault
{
    private string m_ErrorMessage = string.Empty;

    public InvalidRoutingCodeFault(string message)
    {
        this.m_ErrorMessage = message;
    }

    [DataMember]
    public string ErrorMessage
    {
        get { return this.m_ErrorMessage; }
        set { this.m_ErrorMessage = value; }
    }
}

我正在与同事讨论何时抛出错误以及何时不在WCF服务中抛出错误.

有一种观点认为,当服务操作由于某些错误而无法完成工作时,我们只会抛出错误; 由于它,某些东西可能处于无效状态.所以,举一些例子:

• ValidateMember(字符串名称,字符串密码,字符串国家/地区) - >如果未传递强制参数,则会引发错误,因为验证本身无法执行; - >如果发生了一些内部错误就会抛出错误,比如数据库已关闭 - >会在所有其他情况下返回状态合同,指定验证结果(MemberValidated,WrongPassword,MemberNotKnown,...)

• GetMember(int memberId) - >只会在出现故障时抛出错误,在所有其他情况下它会返回成员,如果没有找到则返回null

另一种意见是我们也应该在GetMember找不到该成员时抛出错误,或者在ValidateMember的情况下密码错误.

你怎么看？

我看到了Bertrand Meyer的一篇印刷文章,他在文章中指出可以根据规格生成测试.我的开发团队没有这样做,但这听起来像是一个很好的技术.你是如何根据规格生成测试的？您如何描述通过此方法发现程序错误的成功？