2011-10-11 5 views
6

직렬 포트를 통해 통신하는 제어 회로가 있습니다. 응답 명령이 특정 형식과 일치하지 않으면 오류라고 생각하고 오류 코드를 반환해야하는지 또는 예외를 throw해야하는지 궁금합니다. 예 :C# 오류 코드 vs. 예외

public double GetSensorValue(int sensorNumber) 
{ 
    ... 
    string circuitCommand = "GSV,01," + sensorNumber.ToString(); // Get measurement command for specified sensor. 
    string responseCommand; 
    string expectedResponseCommand = "GSV,01,1,OK"; 
    string errorResponseCommand = "ER,GSV,01,1,62"; 

    responseCommand = SendReceive(circuitCommand); // Send command to circuit and get response. 

    if(responseCommand != expectedResponseCommand) // Some type of error... 
    { 
     if(responseCommand == errorResponseCommand) // The circuit reported an error... 
     { 
     ... // How should I handle this? Return an error code (e.g. -99999) or thrown an exception? 
     } 
     else // Some unknown error occurred... 
     { 
     ... // Same question as above "if". 
     } 
    } 
    else // Everything is OK, proceed as normal. 
     ... 
} 

감사합니다.

답변

8

거의 모든 사례에서 예외를 통해 오류를 전달합니다. 나는 거의 "오류 코드"를 결코 사용하지 않을 것입니다 - 때로는 성공/실패를 int.TryParse 등의 결과와 함께 제공하는 것이 유용하지만이 상황은 그렇게 생각하지 않습니다. 이것은 더 이상의 진행을 멈추어야하는 실제 오류 상태처럼 들리므로 예외가 적절합니다.

편집 : 의견에서 언급했듯이 오류를보고하는 회로가 실제로 "예상"이고 발신자가이를 처리 할 수 ​​있어야하고 적극적으로 해당 상황을 찾고 있다면 상태 코드를 사용하는 것이 합리적입니다.

불행하게도 오류 처리 ... 우리가 정말 아직까지 소프트웨어 공학에 도착하지 않은 것들 중 하나입니다

+0

재미있는; 나는 당신이 표준 오류 처리를위한 예외를 추천하고 싶다는 것에 놀랐다. 비정상적이거나 예기치 않은 상황에 대한 예외를 예약하지 않겠습니까? –

+0

@JohnWeldon : 아니요. 오류가 발생하여 호출 코드가 모든 것이 정상적으로 진행되지 않아야 함을 의미합니다. "* 응답 명령이 특정 형식과 일치하지 않으면 오류라고 생각합니다." –

+0

즉프로그램의 정상적인 흐름은이 사건을 다루기위한 것이 아닙니다. 이 경우 예외 사용에 동의합니다. 그러나 프로그램이 정상적으로이 오류 조건에 응답 할 것으로 예상되는 경우 예외를 사용하지 않습니다. 그 질문에 대한 나의 해석은 후자이지만, 전자는 그럴 듯하다. –

2

예외가 발생하는 경우에 좋습니다. 이 메서드의 호출자는 "합법적 인"출력과 오류 조건을 구분할 수 있기 때문입니다. 오류 코드를 반환하면 여전히 숫자 값이므로 발신자가 제어 회로의 출력으로 잘못 해석 할 수 있습니다.

3

엄밀히 당신이 '특별한'상황에있을 때 예외가 사용되는 말, 즉, 하나는 당신이 기대하지 않을 것입니다. 그것은 나를라면

아마 첫 번째 경우에 오류 코드 (알려진 오류 응답)을 반환하고, 두 번째 경우에서 예외 (알 수없는 오류 코드) 개인적으로

+0

+1 "예기치 못한 일이 예상 됨"- 보험 가입 (= 시도 + 포기)과 같이 운전 규칙을 존중하지 않는 사람이 나중에 보험 회사가하지 않았 음을 알게됩니다 필요한 것은 무엇인가 (예외 처리). – Arun

2

를 던질 것, 내가 다루는 좋아 어떤 종류의 응답 객체를 정의함으로써이 상황. 나는이 일을 경험하고 예외적 인 것으로 간주되어야하는 무게로 이것을 통해 도착했습니다. 일부 장치와 연결되어 있고 사용자가 장치를 껐다가 켜면 예외적 인 상황이며 예외가 발생합니다.

장치에 대한 특정 메서드 호출이 실패하거나 뭔가가 발생하는 경우에는 예외는 아니지만 오류입니다. 나는 double을 반환 할 때 매직 넘버를 정의하고 싶지 않고 예외를 던지기를 원하지 않는다. 그래서, 다음과 같이 정의합니다 :

여기서 구체적인 것은 중요하지 않습니다. 당신이 원하는 방법의 클라이언트에 맞게 조정할 것입니다. 이 예제에서 클라이언트 API는 유효성을 검사하고, 그렇다면 반환 값을 사용합니다 (매직 넘버도 예외도 없음). 패러다임은 무엇보다 중요합니다. 내가 본대로, 당신은 객체 지향 언어를 사용하고 있습니다. 그래서 당신은 객체를 사용할 수도 있습니다. :)

+0

덧붙여 말하자면, 장치 API에서 여러 반환 유형이있는 경우 DeviceResult 을 반환 값을 "T"로 정의 할 수 있습니다. –

0

오류 코드.

  1. 예외 예외는 반환 값보다 느리게 작동합니다.
  2. 메서드 시그니처를 자유롭게 디자인 할 수 있으므로 원하는 형식을 반환 할 수 있습니다. 의미있는 방식으로 확장 할 수없는 특정 유형을 반환해야한다면 확실히 예외를 던져야합니다.
  3. 메서드를 호출 할 때 오류 코드보다 예외를 간과하는 것이 더 쉽습니다. 메소드가 던지는 예외를 문서화해야하고 다른 개발자가 읽을 수 있기를 바랍니다.
  4. GetSensorValue 메서드의 응답에는 다른 경로가 있습니다. "행복한 경로"는 분명히 예상되고 가장 흥미로운 경로입니다. 그러나 소비자가 덜 유쾌한 경로의 결과를 처리 할 수 ​​있다는 것을 안다면 "불행한 경로"응답이 예상되므로 오류 코드와 함께 사용하는 것이 좋습니다.
  5. 많은 예외를 throw하면 디버거 예외 설정에 따라 디버거가 끊어 질 수 있습니다.
  6. 오류 코드를 반환하면 분명히 응답 유형이 더 복잡해 지므로 값을 언 래핑하는 데 더 많은 코드가 필요합니다. 하지만 try-catch 대신 "if (response.Status == Statuses.Success) {var value = response.Value;}"를 읽고 쓰는 것이 정말 어렵습니까?

는 예외를 발생하는 것이 좋습니다 : 당신이 당신의 메소드 호출이 실패 할 예견 수있는 경우 (당신이 그것을 수행하기 전에 작업을 수행 할 수 있는지 확인)

  1. 가. "수행"메소드는 오류 코드도 리턴하도록 구현 될 수 있지만,이 점검 수행 메소드 쌍은 패턴으로 간주됩니다.
  2. 의미있는 방식으로 응답 유형을 확장 할 수는 없지만 방법의 계약에 의해 예측되지 않은 상태로 응답을 보내야합니다.
  3. 이전과 마찬가지로 "행복한 경로"결과 만 반환하는 것이 좋습니다.
0

나는 때문에 몇 가지 간단한 사실에 대부분의 경우에 예외를 사용하는 것이 좋습니다 것입니다 :

  1. 예외가 전역, 모든 C#의 -developers 디버깅을 위해 그것을 사용하는 방법 (희망과) 예외가 무엇인지 알고 .
  2. 예외는 모든 호출 메소드에서 가장 가까운 "try catch"로 나뉩니다. 여러 레이어가 있고 가장 안쪽 레이어가 예외를 throw하면 원하는 레이어 (일반적으로 가장 바깥 쪽 또는 두 번째 바깥 쪽 레이어)에서 예외를 처리 할 수 ​​있습니다.
  3. 대부분의 프로젝트 유형에는 간단한 전역 예외 처리 코드를 구현하기 위해 재정의하거나/가입 할 수있는 일종의 대체 가능한 메소드 또는 이벤트가 있습니다. 이것은 오류 메시지의 형식을 지정하고, 기록을 수행하고, 메일을 보내고, 신들에게 (또는 예외를 처리 할 때 무엇을 하든지간에)기도하는 것을 간단하게합니다.

    1. 그것은 예외를 던질 무료 아니에요 :

    하지만 고려해야 할 몇 가지가 있습니다. 코드를 100 % 최적화해야한다면 예외를 던지면 피해야 할 대상이 될 수 있습니다.

  4. 예외에는 많은 정보가 필요하지 않을 수 있습니다. 정말로 원하는 경우 사용자에게 간단한 오류 메시지를 표시하려면 스택 추적이 필요합니까?

그러나 일반적으로, 내가 말할 것 : 예외에 충실, 그것이 약간의 성능 올 수도 있지만 심지어 처리하기 위해, 간단한 정보, 디버깅 및 쉬운 비용