Question

我不确定在网络服务中抛出异常是个好主意。如果不是堆栈跟踪，我也不会介意。这不是我不想要的。

我已经围绕几个实现进行了研究，似乎对此没有达成共识。例如，CampaignMonitor会返回一个Result对象，而其他人则不会。

从架构上讲，我不确定返回一个返回对象是否有意义，当然异常是一个异常，但我对Return对象的喜好是对最终用户来说它是一个更优雅的解决方案。

有没有人有更好的解决方案？

修改

BTW我正在使用ASMX Web服务，其中打开CustomErrors不是一种选择。

Answer 1

不要让你在网络服务中的事实混淆了这个问题。这只是一个实现细节。

使用正常的异常处理策略。最佳实践说不要在低级别代码中捕获异常 - 除非您可以在那里解决该异常并继续正常进行。应该将异常提升到表示层，以便可以通知用户错误。

因此，应用于Web服务 - 通常抛出异常（导致SoapFault）。这允许调用客户端代码使用它的内置异常处理标准来处理它。

Answer 2

你在谈论什么堆栈痕迹？你试过这个吗？

在ASMX和WCF服务中，未捕获的异常将转换为SOAP Fault。在这两种情况下，它们都可以配置为不包含任何堆栈跟踪。实际上，这是WCF中的默认值。

因此，返回这样的错误的正确方法是通过错误。产生错误的一种方法是抛出并不处理异常。

Answer 3

一种方法是分离系统和业务错误。（系统错误：例如格式错误的请求，用户未授权等;业务错误：例如方法UpdateCars导致错误，用户不拥有任何汽车）。

如果出现业务错误，请返回包含错误说明的响应对象;如果出现系统错误，请抛出异常。

Answer 4

你可以澄清一下吗？ Web服务的服务器端可以抛出异常。 Web服务的服务器端可以向客户端返回消息。该消息可能包含错误信息，并且该错误信息可能具体包括异常详细信息。或者它可能不会。在客户端，您通常有一个生成的代理来处理来自服务器的消息。如果该响应包含错误信息，则此代理可能会生成异常。

您想知道这个场景的哪个部分？

Answer 5

我认为抛出异常通常是一种更好的设计模式，然后返回结果。我想您必须做的是在Web服务中隐藏堆栈跟踪，方法是将以下模式应用于作为Web服务公开的每个方法：

public void MyWebServiceMethod（）   {
    尝试
    {
 ///Do something that may cause an error
} catch（Exception ex）
     {         抛出新的ApplicationException（“用户友好   异常的解释“）;

}

}

或者您也可以

catch（Exception ex）{ 抛出前}

如果重新抛出异常，则会从Web服务的客户端隐藏原始堆栈跟踪。

Answer 6

我不明白为什么你不能两者兼顾？捕获异常，将其记录（记录到数据库或文件），然后返回错误代码。通过这种方式，您可以正常执行webservice调用，并且还可以通知错误，并且您可以在其他位置进行进一步调试。

Web服务是否应该抛出异常或结果对象

6 个答案: