2010-06-15 3 views
0

제 3 자 API에 대한 HTTP 호출을 만드는 아래에서이 메서드를 만들었습니다. 나는 이것을 최선의 방법으로 다루고 있는지에 대한 의견을 원합니다. 호출이 실패하면 응답이 null이 아닌 경우에만 ExistsInList bool 값을 반환해야합니다. 하지만 마지막 return 문에서 본질적으로 다른 return selectResponse == null을 수행하지 않아도됩니까? false : selectResponse.ExistsInList; 캐치의 이전 반환과 마찬가지로 먼저 null을 확인 하시겠습니까?웹 서비스 호출 래퍼에서 반환 값 처리

내가 접근하고있는 방식이 중복되는 것처럼 보입니다. 마지막 반환에서 다시 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; 
} 

답변

4

제안 # 1 : 예외는 먹지 마십시오! 당신은 당신이 무시하고있는 어떤 종류의 예외가 있는지 전혀 모릅니다. 이 시점에서 예외가 발생하면 제 3 자 API에 문제가 있다는 것을 암시하고 있지만 그렇지 않을 수도 있습니다.

내 제안은 최소한 예외를 기록하고 을 누른 다음 무시하십시오. 개발 중에 로그를 확인하여 어떤 종류의 예외가 발생하는지 확인할 수 있습니다. 래퍼의 코드를보고 합리적으로받을 수있는 예외 (또는 통신 오류와 같은 합리적인 일이 발생했음을 의미)를 이해합니다.

그런 다음이 코드를 변경하여 해당 API에 문제가 있음을 나타내는 예외 만 catch합니다. 나머지는 전파하거나, 처리 방법을 알고있는 코드에 의해 처리되거나, 올바르게 기록 할 코드에 의해 처리되도록 허용되어야합니다.

이렇게 코드를 정리해야하는 사람의 예는 "Asked to fix bugs in a program, you find over 100 instances of…"을 참조하십시오.

+0

예,'throw;'en이 아닌 예외는 모두 기록되어야합니다. – Nate

+0

좋아,하지만 여기에 예외가 생기면 신경 쓰지 않기 때문에이 경우 예외가 발생하면 여기 전체 응용 프로그램을 중단하고 싶지는 않습니다 ... 비즈니스 논리/시나리오에 의존하는이 특정 메서드와는 관련이 없습니다 – PositiveGuy

+0

나는 너와 네이트의 말에 동의합니다 ... 감사합니다, 기억하기 좋은 경험 법칙. 그러나 우리가 예외를 두지 않는다면 예외를 기록하고 싶지 않습니다. 예를 들어, 두 번째 호출이 실패하면 ok입니다. 단지 억제 목록에 없다는 것을 의미합니다. 우리는 그 중 하나가 있는지 확인하기 위해 빠른 점검을하고 있습니다. 그렇다면 조금 정리하고 그 레코드를 제거하십시오. 존재하지 않거나 SelectResponse가 실패하면 우리는 나중에 다시 시도 할 수 있습니다. 그러나 실패한 경우 정리의 목적으로 레코드의 체크 만하기 때문에 중요하지 않습니다. 우리는 그와 같은 오류를 볼 필요가 없습니다. – PositiveGuy