Question

最好将Web服务方法/调用包装到try / catch块中吗？

我不是Web服务请求往往是.NET桌面应用程序崩溃的原因吗？所以我认为所有的调用都应该包含在try / catch中以防止这种情况发生。

好主意？

此外，它应该抛出异常还是只有一个空的捕获？

Answer 1

我假设您正在使用WCF，因为您的问题已被标记。使用WFC进行异常处理的一个好习惯是不允许异常通过线路传递给消费者，而是抛出有意义的FaultExceptions。

如果有可能产生异常，你应该总是在你的操作中有一个try ... catch块。如果允许原始摘要冒泡，则只会产生两种情况：如果您已将服务配置为允许出现故障中的异常详细信息，则会自行暴露您的服务内部，以防止出现安全漏洞。或者您没有在服务中配置此消息，消费者会收到一条非常通用的消息，指出出现了问题，这对他们或支持团队来说并不是很有用。

您应该做的是声明一个或多个FaultExceptions，具体取决于您希望用户从您的操作接收的消息，在操作声明中将它们装饰为FaultContracts。然后你可以尝试...捕获特定的异常并抛出特定的错误。你也可以尝试捕获异常并抛出非常一般的错误。

这里的关键是，没有透露太多关于内部操作的信息 - 尤其是堆栈痕迹！

错误只是另一个数据契约，因此它在您的WSDL中声明。这意味着您的消费者可以专门捕获故障，并且可以对您的操作引发的错误作出反应，就好像它是从代码中抛出的异常一样。

希望这有帮助。

乔。

Answer 2

没关系，但是尝试捕获可以处理的异常类型。

避免捕获任何“异常”，或者，如果您这样做，请记录和/或提醒用户和/或重试调用Web服务。

如果它是一个Windows窗体应用程序，我通常将最后一个“异常”捕获包装在#if DEBUG块中，以避免在调试或测试时隐藏异常。

#if !DEBUG
catch (Exception ex)
{
    // show messagebox, log, etc
}
#endif

Answer 3

是的，您应该在try-catch中包装Web服务调用。不要使用空捕获，因为它们（大多数）是纯粹的邪恶。你的catch块至少应该记录异常。我不知道您的应用程序逻辑，但可能会向用户显示一些消息（例如“因服务器未提取信息而导致的技术错误”）。

Answer 4

using System;
using System.ServiceModel;
using Entities; //my entities
using AuthenticationService; //my webservice reference

namespace Application.SL.Model
{
    public class AuthenticationServiceHelper
    {
        /// <summary>
        /// User log in
        /// </summary>
        /// <param name="callback"></param>
        public void UserLogIn(Action<C48PR01IzhodOut, Exception> callback)
        {
            var proxy = new AuthenticationServiceClient();

        try
        {
            proxy.UserLogInCompleted += (sender, eventargs) =>
            {
                var userCallback = eventargs.UserState as Action<C48PR01IzhodOut, Exception>;
                if (userCallback == null)
                    return;

                if (eventargs.Error != null)
                {
                    userCallback(null, eventargs.Error);
                    return;
                }
                userCallback(eventargs.Result, null);
            };
            proxy.UserLogInAsync(callback);
        }
        catch (Exception ex)
        {
            proxy.Abort();
            ErrorHelper.WriteErrorLog(ex.ToString());
        }
        finally
        {
            if (proxy.State != CommunicationState.Closed)
            {
                proxy.CloseAsync();
            }
        }
        }
}

这是一个好的做法还是有改进的余地？

Answer 5

这是一个可能导致抛出异常的情况，所以是的，它应该包装在try catch块上。

如何处理异常处理程序，它取决于程序逻辑......

Answer 6

将一个Web服务方法放在try catch块中是一个好主意，因为您声明您不希望因为Web服务方法出错而导致调用应用程序崩溃。

此外，您可以考虑让所有的Web服务方法都返回一个可以包含调用状态的结构或小类，而不是将异常抛回客户端，无论如何都无法对其执行任何操作。错误代码和可以解释错误的友好消息。

在try / catch块中包装Web服务

6 个答案: