处理来自Web Service Call Wrapper的返回值

我在下面创建了此方法，该方法对第三方API进行HTTP调用。我只想就我是否以最好的方式处理这个问题发表意见。如果调用失败，则只有在响应不为空时，我才需要返回ExistsInList布尔值。但在最后一个return语句中，我不必基本上做另一个返回selectResponse == null吗？ false：selectResponse.ExistsInList;首先检查null，就像之前的catch返回一样？处理来自Web Service Call Wrapper的返回值

刚才似乎多余的方式我接近这一点，我不知道我是否真的需要在最终的回报中再次检查null，但我认为是的，因为你不能总是依靠响应给予即使没有发现错误，您也可以获得有效的答复。

public static bool UserExistsInList(string email, string listID) 
{ 
    SelectRecipientRequest selectRequest = new SelectRecipientRequest(email, listID); 
    SelectRecipientResponse selectResponse = null; 

    try 
    { 
     selectResponse = (SelectRecipientResponse)selectRequest.SendRequest(); 
    } 
    catch (Exception) 
    { 
     return selectResponse == null ? false : selectResponse.ExistsInList; 
    } 

    return selectResponse.ExistsInList; 
}

来源

2010-06-15 PositiveGuy

建议＃1：不要吃异常！你不知道你忽略了什么样的例外。您认为此时的任何例外都意味着第三方API存在问题，但情况可能并非如此。

我的建议是至少记录异常，然后然后忽略它。一定要在开发过程中查看日志，以便了解您获得的异常情况。查看包装中的代码，以了解可能合理接收哪些异常（或更确切地说，哪些意味着发生了合理的事情，例如通信失败）。

然后，更改此代码以仅捕获意味着该API的问题的异常。其余的应该被允许传播，由知道如何处理它们的代码处理，或者通过将会正确记录它们的代码来处理。

查看“Asked to fix bugs in a program, you find over 100 instances of…”的例子，这个人不得不像这样清理代码。

来源

2010-06-15 20:26:44

是的，任何不是'throw;'en的异常都必须记录下来。 – Nate 2010-06-15 20:29:00

好的，但我不想在这里停止我的整个应用程序，如果我在这种情况下得到一个异常，因为我不在乎这里是否有异常...这对于这种依赖于业务逻辑/场景的特定方法是无关紧要的 – PositiveGuy 2010-06-15 20:50:42

我同意你和Nate的看法......谢谢你，经验值得记住。但是如果我们不关心它们，我们不想记录异常。例如，如果第二次呼叫失败，那没关系，这只是意味着它们不在禁止列表中，这很好。我们只是做一个快速检查，看看是否有人在那里，如果是这样做一点清理并删除该记录。如果它不存在或者SelectResponse失败，我们可以稍后重试，但如果失败则不是关键，因为它仅仅是为了清理目的而对它们的记录进行检查。我们不需要看到大量的错误。 – PositiveGuy 2010-06-15 20:52:37

处理来自Web Service Call Wrapper的返回值

回答

相关问题