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

本文关键字：web SOAP 服务 API REST 响应 应用程序 处理 不可靠 | 更新日期: 2023-09-27 18:16:44

我不喜欢通过try catch块进行错误处理，但在这种情况下，我没有看到任何其他清晰的路径。在我的代码中，我调用了一个web服务，但在不久的将来，它可能很快就会成为一个rest API。这个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
    }

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

关于如何处理异常情况有两个截然相反的阵营。一个阵营倾向于异常，另一个阵营倾向于从可能以某种形式失败的函数返回错误代码(或类似代码)。什么是"更好"是有争议的，并且取决于情况(例如:http://www.joelonsoftware.com/items/2003/10/13.html关于"错误代码"阵营的论点)。我之所以这么说，是因为据我所知，您希望myProxy.Retrieve在超时时返回一些错误代码，而不是抛出异常。这可能是合理的，但事实并非如此，你无法改变这一点。整个。net框架几乎无处不在地使用异常(有时在可能被认为是"正常流程的一部分"的情况下，尽管正常流程的定义也不是微不足道的)。

长话短说,很多代码中使用。net将抛出异常错误,甚至在sutations 你考虑正常,你必须接受这样的条件并采取相应行动,捕捉和处理它们,这是完全正常的。通常有2点反对异常:

  1. 正如你在评论中提到的，它们需要花费一些时间和资源来构建。对于每秒执行数千个操作的代码来说，这是合理的关注，这些操作会抛出数千个异常。但是，在您的情况下，请求需要30-60秒，因此与此相比，异常成本绝对为零。

  2. 它们改变控制流，有时将其移动到离实际异常源很远的地方(如goto语句)。为了处理这个问题(如果你在"错误代码"阵营，但无论如何都必须处理异常)，你应该把try-catch块尽可能地放在产生它的函数附近，并立即处理异常，因为你确切地知道它发生的位置和原因。

因此，用try-catch块包围soap服务调用并处理超时异常是实现此目的的最佳方法，并且绝对没有必要尝试避免抛出此异常。在自己的代码中，您可能不想在"正常"条件下抛出异常，但如果在第三方代码中发生异常，您必须处理而不是避免它们。

相关文章：