处理来自C#应用程序的不可靠/无响应的SOAP web服务或REST API

我不喜欢通过try-catch块进行错误处理，但在本例中，我没有看到任何其他清晰的路径。在我的代码中，我正在调用一个web服务，但在不久的将来它可能很快成为RESTAPI。此web服务是外部的，不幸的是，它不是100%可靠的。我需要做的是创建能够处理无响应web服务的代码。今天看起来是这样的：

SOAP代理被设置为具有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
    }

---

关于如何处理特殊情况，有两个对立的阵营。一个阵营倾向于异常，另一个阵营倾向于从可能以某种形式失败的函数返回错误代码（或类似代码）。什么是“更好”是有争议的，并且取决于具体情况（参见示例：“错误代码”阵营的参数）。我这样说是因为据我所知，您希望

myProxy.Retrieve

在超时时返回一些错误代码，而不是抛出异常。这可能是合理的，但事实并非如此，你无法改变这一点。整个.NET框架几乎在任何地方都使用异常（有时在可能被视为“正常流的一部分”的情况下，尽管正常流的定义也并非微不足道）

长话短说-你在.NET中使用的很多代码都会在错误上抛出异常，即使在强< > >的正常情况下，你必须与之共存，并采取相应的行动——抓住并处理它们——这是完全正常的。例外情况通常有两点：

正如您在评论中提到的，它们需要花费一些时间和资源来构建。在某些每秒执行数千次操作的代码中，这是一个合理的问题，而这些操作会引发数千次异常。然而，在您的情况下，请求需要30-60秒，因此，与此相比，异常成本绝对为零

它们更改控制流，有时将其移动到远离实际异常源的地方（如goto语句）。要处理此问题（如果您处于“错误代码”阵营，但无论如何都必须处理异常），您应该将try-catch块放在尽可能靠近生成它的函数的位置，并立即处理异常，因为您确切地知道异常发生的位置和原因。如果您已经在示例中执行了此操作，则会出现此问题

---

因此，在soap服务调用中使用try-catch块和处理超时异常是最好的方法，完全没有必要尝试避免抛出此异常。您可能不希望自己在自己的代码中在“正常”条件下抛出异常，但如果在第三方代码中发生这种情况，您必须处理而不是避免它们。

为什么“我不喜欢通过try-catch块进行错误处理”？如果你想不惜一切代价避免这样做，这一定是一个非常有力的理由。@softwareengineering的Evk：当构造异常对象时，运行时会做很多工作——将堆栈跟踪放在一起，找出异常处理的位置等等。如果使用流控制语句进行流控制，则不需要扩展内存和CPU资源中的所有这些成本。此外，还有一个语义问题。例外情况适用于例外情况，而非正常流量控制。我们应该使用异常处理来处理意外/异常情况，而不是像正常的程序流程一样。谢谢您的输入