37

我们目前正在争论是否最好通过 WCF 通道抛出错误，而不是传递指示状态的消息或来自服务的响应。

错误来自 WCF 的内置支持，您可以在其中使用内置的错误处理程序并做出相应的反应。然而，这会带来开销，因为在 .NET 中引发异常可能会非常昂贵。

消息可以包含必要的信息来确定您的服务调用发生了什么，而无需引发异常的开销。然而，它确实需要几行重复的代码来分析消息并确定其内容之后的操作。

我们尝试创建一个可以在我们的服务中使用的通用消息对象，这就是我们想出的：

public class ReturnItemDTO<T>
{
    [DataMember]
    public bool Success { get; set; }

    [DataMember]
    public string ErrorMessage { get; set; }

    [DataMember]
    public T Item { get; set; }
}

如果我的所有服务调用都返回此项目，我可以持续检查“成功”属性以确定一切是否顺利。然后，如果需要，我会在指示出现问题的事件中收到错误消息字符串，以及包含 Dto 的通用项目。

异常信息必须记录到中央日志服务，而不是从服务传回。

想法？评论？想法？建议？

进一步澄清我的问题

我遇到的错误合同问题是传达业务规则。

例如，如果有人登录，并且他们的帐户被锁定，我该如何沟通？他们的登录显然失败了，但由于“帐户锁定”的原因而失败。

我也是：

A) 使用布尔值，在消息帐户被锁定的情况下抛出错误

B）返回带有相关信息的AuthenticatedDTO

4

3 回答 3

32

然而，这会带来开销，因为在 .NET 中引发异常可能会非常昂贵。

您正在将对象序列化和反序列化为 XML 并通过慢速网络发送它们。与此相比，抛出异常的开销可以忽略不计。

我通常坚持抛出异常，因为它们清楚地传达出了问题，并且所有Web 服务工具包都有处理它们的好方法。

在您的示例中，我会抛出带有“帐户锁定”消息的 UnauthorizedAccessException。

澄清： .NET wcf 服务默认将异常转换为 FaultContracts，但您可以更改此行为。MSDN：指定和处理合同和服务中的错误

于 2008-09-17T09:09:10.910 回答
6

如果您考虑像调用任何其他方法一样调用服务，这可能有助于正确看待事情。想象一下，如果您调用的每个方法都返回一个状态，而您需要检查它是真还是假。这会变得相当乏味。

result = CallMethod();
if (!result.Success) handleError();

result = CallAnotherMethod();
if (!result.Success) handleError();

result = NotAgain();
if (!result.Success) handleError();

这是结构化错误处理系统的优势之一，您可以将实际逻辑与错误处理分开。您不必继续检查，如果没有抛出异常，您就知道它是成功的。

try 
{
    CallMethod();
    CallAnotherMethod();
    NotAgain();
}
catch (Exception e)
{
    handleError();
}

同时，通过返回结果，您将更多的责任放在了客户身上。您可能很清楚要检查结果对象中的错误，但是 John Doe 进来并开始调用您的服务，因为没有抛出异常而忘记了任何错误。例外的另一个巨大优势是，当出现问题并需要处理时，它们会给我们一个很好的耳光。

于 2012-09-25T05:39:43.657 回答
0

我会认真考虑使用 FaultContract 和 FaultException 对象来解决这个问题。这将允许您将有意义的错误消息传递回客户端，但仅限于发生故障情况时。

不幸的是，我目前正在参加培训课程，因此无法写出完整的答案，但幸运的是，我正在学习 WCF 应用程序中的异常管理。今晚我会回复更多信息。（对不起，这是一个微弱的答案）

于 2008-09-17T09:13:39.777 回答