Question

我不喜欢通过try catch块进行错误处理，但在这种情况下我没有看到任何其他明确的路径。在我的代码中，我调用了一个Web服务，但在不久的将来它很快就会成为一个rest API。此Web服务是外部的，遗憾的是不是100％可靠。我需要做的是创建可以处理无响应的Web服务的代码。今天它看起来像这样：

SOAP Proxy设置为超时120秒

var myProxy = new WebReference.ProxyClass();
myProxy.Timeout = 120000;

try
{
    CreditInformation creditInformation = myProxy.Retrieve(prospect.CorporateIdentity);
    agreement.Company.Name = creditInformation.CompanyName;
    agreement.FinancialInformation.NetRevenue = creditInformation.Revenue / 1000;
}
catch (WebException e) when (e.Status == WebExceptionStatus.Timeout)
{
    logger.Error("Web service timed out");
}

//Continiue running code even if the web service time out

这是一个不好的标准吗？它可以更好地执行吗？正如我之前所说，我不喜欢通过try catch处理错误，但这似乎是可行的。我想创建一些代码来检查Web服务是否响应，但我决定不这样做。这是因为Web服务非常慢，默认情况下请求需要30-60秒，这会让用户等待更长时间，以便检查它是否已启动。另一种解决方案可能是ping主机，但不能保证服务实际上是正常的。示例代码：

HttpWebResponse response = (HttpWebResponse)request.GetResponse();
if (response != null && response.StatusCode == HttpStatusCode.OK)
    {
        //Do stuff here
    }

Answer 1

关于如何处理异常情况，有两个相反的阵营。一个阵营更喜欢异常，另一个阵营更喜欢从一个可能以某种形式失败的功能返回错误代码（或类似代码）。什么是＆＃34;更好＆＃34;是可论证的和依赖于情境的（参见例如：http://www.joelonsoftware.com/items/2003/10/13.html用于＆＃34;错误代码＆＃34;阵营的参数）。我告诉你这是因为据我所知你更希望myProxy.Retrieve在超时时返回一些错误代码，而不是抛出异常。这可能是合理的，但这不是它的工作方式，你无法改变它。整个.NET框架几乎在所有地方使用异常（有时在可能被考虑的情况下＃34;正常流程的一部分＆＃34;，尽管正常流程的定义同样不重要）。

长话短说 - 你在.NET中使用的很多代码都会在错误上引发异常，即使在你认为正常的情况下也是如此，你必须忍受它并采取相应的行动 - 抓住并且处理它们 - 这完全正常。通常有2点反对例外：

正如您在评论中提到的那样，他们需要花费一些时间和资源来构建。这在一些代码中是合理的，它每秒执行数千次操作，并且这些操作会产生数千个异常。但是，在您的情况下，请求需要 30-60秒，因此异常成本与此相比绝对为零。
他们改变了控制流程，有时将其移动到离实际异常源很远的地方（如goto语句）。要处理这个问题（如果你在＆＃34;错误代码＆＃34;阵营，但是必须使用异常），你应该尽量把try-catch块放到产生它的函数上，并处理异常因为你确切知道它发生的地点和原因。如果你已经在你的例子中做了什么。

因此，使用try-catch块调用周围的soap服务并处理超时异常是最好的方法，并且绝对不需要尝试避免抛出此异常。您可能不想在＆＃34; normal＆＃34;中抛出异常。在你自己的代码中使用自己的条件，但如果在第三方代码中发生这种情况 - 你必须处理而不是避免它们。

从C＃应用程序处理不可靠/无响应的SOAP Web服务或REST API

1 个答案: