C에서 모든 작은 오류를 확인해야합니까?

훌륭한 프로그래머는 프로그램의 모든 단일 결과를 처리 할 강력한 코드를 작성해야합니다. 그러나 오류가 발생하면 C 라이브러리의 거의 모든 함수가 0 또는 -1 또는 NULL을 반환합니다.

예를 들어 파일을 열려고 할 때와 같이 오류 검사가 필요한 경우가 있습니다. 그러나 나는 종종 필요하다고 느끼지 않기 때문에 printf또는 오류로 인해 오류 검사를 무시 malloc합니다.

if(fprintf(stderr, "%s", errMsg) < 0){
    perror("An error occurred while displaying the previous error.");
    exit(1);
}

특정 오류를 무시하는 것이 좋습니까, 아니면 모든 오류를 처리하는 더 좋은 방법이 있습니까?

일반적으로 코드는 적절한 곳에서 예외적 인 조건을 처리해야합니다. 예, 이것은 모호한 진술입니다.

소프트웨어 예외 처리 기능이있는 고급 언어에서는 종종 "실제로 무언가를 할 수있는 방법에서 예외를 잡아라"라고 말합니다. 파일 오류가 발생한 경우 실제로 사용자에게 "파일을 디스크에 저장하지 못했습니다"라고 말할 수있는 UI 코드로 스택을 버블 링 할 수 있습니다. 예외 메커니즘은 "모든 작은 오류"를 효과적으로 삼키고 적절한 위치에서 암시 적으로 처리합니다.

C에서는 그 사치가 없습니다. 오류를 처리하는 몇 가지 방법이 있으며, 그 중 일부는 언어 / 라이브러리 기능이며, 일부는 코딩 방법입니다.

특정 오류를 무시하는 것이 좋습니까, 아니면 모든 오류를 처리하는 더 좋은 방법이 있습니까?

특정 오류를 무시 하시겠습니까? 아마도. 예를 들어 표준 출력에 대한 쓰기가 실패하지 않는다고 가정하는 것이 합리적입니다. 그것이 실패하면 어쨌든 사용자에게 어떻게 말할 것입니까? 예, 특정 오류를 무시하거나 오류를 방지하기 위해 방어 적으로 코드를 작성하는 것이 좋습니다. 예를 들어, 나누기 전에 0을 확인하십시오.

모든 또는 적어도 대부분의 오류를 처리하는 방법이 있습니다.

1. 오류 처리를 위해 gotos와 유사한 점프를 사용할 수 있습니다 . 소프트웨어 전문가들 사이에 논쟁의 여지가 있지만, 특히 임베디드 및 성능에 중요한 코드 (예 : Linux 커널)에서 소프트웨어를 올바르게 사용하고 있습니다.

2. 계단식 ifs :

   if (!<something>) {
     printf("oh no 1!");
     return;
   }
   if (!<something else>) {
     printf("oh no 2!");
     return;
   }
   

3. 첫 번째 조건 (예 : 파일 열기 또는 만들기)을 테스트 한 다음 후속 작업이 성공한다고 가정합니다.

강력한 코드가 좋으며 오류를 확인하고 처리해야합니다. 코드에 가장 적합한 방법은 코드의 기능, 장애의 심각도 등에 따라 달라지며 사용자 만이 진정으로 대답 할 수 있습니다. 그러나 이러한 방법은 실제 테스트를 통해 실제 코드에서 오류를 확인하는 방법을 확인할 수있는 다양한 오픈 소스 프로젝트에서 전투 테스트를 거쳤습니다.

그러나 오류가 발생하면 C 라이브러리의 거의 모든 함수가 0 또는 -1 또는 NULL을 반환합니다.

예,하지만 어떤 기능 을 사용했는지 알고 있습니까?

실제로 오류 메시지에 넣을 수있는 많은 정보가 있습니다. 호출 된 함수, 호출 한 함수의 이름, 전달 된 매개 변수 및 함수의 리턴 값을 알고 있습니다. 그것은 매우 유익한 오류 메시지에 대한 많은 정보입니다.

모든 함수 호출에 대해이 작업을 수행 할 필요는 없습니다. 그러나 실제로 필요한 정보가 유용한 정보 인 경우 "이전 오류를 표시하는 동안 오류가 발생했습니다"라는 오류 메시지가 처음 표시 될 때 즉시 해당 오류 메시지가 표시됩니다. 문제 해결에 도움이되는 정보를 제공하는 오류 메시지.

TLDR; 거의 오류를 무시해서는 안됩니다.

C 언어에는 각 라이브러리 개발자가 자체 솔루션을 구현할 수있는 오류 처리 기능이 부족합니다. 보다 현대적인 언어에는 예외가 내장되어있어이 특정 문제를 훨씬 쉽게 처리 할 수 ​​있습니다.

그러나 C에 갇혀 있으면 그러한 특권이 없습니다. 불행히도 원격 실패 가능성이있는 함수를 호출 할 때마다 가격을 지불하면됩니다. 그렇지 않으면 실수로 메모리의 데이터를 덮어 쓰는 것과 같은 훨씬 더 나쁜 결과를 겪게됩니다. 따라서 일반적으로 항상 오류를 확인해야합니다.

귀국 여부를 확인하지 않으면 fprintf버그가 남아있을 가능성이 높습니다. 최상의 경우 사용자가 기대하는 것을 수행하지 못하고 최악의 경우 비행 중에 전체가 폭발합니다. 그런 식으로 자신을 훼손 할 변명이 없습니다.

그러나 C 개발자는 코드를 쉽게 유지 관리하는 것이 귀하의 임무입니다. 따라서 때로는 애플리케이션의 전체 동작에 위협이되지 않는 경우 명확성을 위해 오류를 무시 해도됩니다. .

이 작업을 수행하는 것과 같은 문제입니다.

try
{
    run();
} catch (Exception) {
    // comments expected here!!!
}

빈 캐치 블록 안에 좋은 주석이 없으면 이것이 문제입니다. 호출이 malloc()100 %의 시간 동안 성공적으로 실행될 것이라고 생각할 이유가 없습니다 .

질문은 실제로 언어에 국한된 것이 아니라 사용자에 따라 다릅니다. 사용자 관점에서 질문에 대해 생각하십시오. 사용자는 명령 행에 프로그램 이름을 입력하고 Enter 키를 누르는 등의 작업을 수행합니다. 사용자는 무엇을 기대합니까? 문제가 발생했는지 어떻게 알 수 있습니까? 오류가 발생하면 중재 할 여유가 있습니까?

많은 유형의 코드에서 이러한 검사는 과도합니다. 그러나 원자로의 코드와 같은 신뢰성이 높은 안전 핵심 코드에서 병리학 적 오류 점검 및 계획된 복구 경로는 일상 업무의 일부입니다. "X가 실패하면 어떻게 되나요? 어떻게 안전한 상태로 돌아가나요?"라고 묻는 데 시간이 걸리는 것으로 여겨집니다. 비디오 게임용 코드와 같이 안정성이 떨어지는 코드에서는 훨씬 적은 오류 검사로 벗어날 수 있습니다.

또 다른 유사한 접근법은 오류를 포착하여 실제로 상태를 얼마나 개선 할 수 있습니까? 예외를 자랑스럽게 포착하는 C ++ 프로그램의 수를 셀 수는 없습니다. 실제로 처리해야 할 작업을 알지 못했기 때문에 다시 throw하기 위해 예외 처리를해야한다는 것을 알고있었습니다. 이러한 프로그램은 추가적인 노력으로 얻은 것이 없습니다. 단순히 오류 코드를 확인하지 않는 것보다 실제로 상황을 더 잘 처리 할 수 ​​있다고 생각되는 오류 확인 코드 만 추가하십시오. 즉, C ++에는 예외 처리 중에 발생하는 예외를보다 의미있는 방식으로 포착하기 위해 발생하는 예외를 처리하기위한 특정 규칙이 있습니다 (따라서, 여러분이 직접 만든 장례식 pyre가 점등되도록하기 위해 terminate ()를 호출하는 것을 의미합니다 적절한 영광으로)

병리학적인 방법은 무엇입니까? 필자는 1과 0의 균일 한 분포를 신중하게 선택한 true 및 false 값을 가진 "SafetyBool"을 정의한 프로그램에서 작업했으며 여러 하드웨어 오류 중 하나 (단일 비트 플립, 데이터 버스)를 선택했습니다. 흔적이 깨지는 등)로 인해 부울이 잘못 해석되지 않았습니다. 말할 것도없이, 나는 이것이 이전 프로그램에서 사용되는 범용 프로그래밍 관행이라고 주장하지는 않을 것이다.

• 다른 안전 요구 사항에는 다른 수준의 정확성이 필요합니다. 항공 또는 자동차 제어 소프트웨어에서 모든 반환 값을 확인합니다 (cf. MISRA.FUNC.UNUSEDRET . 기계를 떠나지 않는 빠른 개념 증명으로, 아마도 아닙니다.
• 코딩에는 시간이 걸립니다. 안전하지 않은 중요 소프트웨어의 관련없는 검사가 너무 많으면 다른 곳에서 더 잘 노력할 수 있습니다. 그러나 품질과 비용의 장점은 어디에 있습니까? 디버깅 도구와 소프트웨어 복잡성에 따라 다릅니다.
• 오류 처리는 제어 흐름을 방해하고 새로운 오류를 유발할 수 있습니다. 나는 최소한 오류를보고하는 Richard "network"Stevens의 래퍼 함수를 ​​아주 좋아한다.
• 오류 처리가 성능 문제가되는 경우는 거의 없습니다. 그러나 대부분의 C 라이브러리 호출은 시간이 오래 걸리므로 반환 값을 확인하는 데 드는 비용이 엄청나게 작습니다.

질문에 대한 추상적 인 설명이 조금 있습니다. 그리고 반드시 C 언어를위한 것은 아닙니다.

더 큰 프로그램의 경우 추상화 계층이 있습니다. 엔진, 라이브러리 또는 프레임 워크의 일부일 수 있습니다. 이 레이어는 유효한 데이터를 얻는 날씨에 신경 쓰지 않거나 출력은 기본값 0인 -1, null등이됩니다.

그런 다음 추상 계층에 대한 인터페이스가 될 계층이 있으며, 많은 오류 처리 및 종속성 주입, 이벤트 수신 등과 같은 다른 작업을 수행합니다.

나중에 규칙을 설정하고 출력을 처리하는 구체적인 구현 계층을 갖게됩니다.

따라서이 부분은 단순히 코드 작업에서 오류 처리를 완전히 제외하는 것이 더 좋습니다. 해당 부분은 단순히 해당 작업을 수행하지 않기 때문입니다. 그런 다음 출력을 평가하고 오류를 가리키는 프로세서가 있습니다.

이것은 대부분 코드 가독성과 확장 성을 향상시키는 책임을 분리하기 위해 수행됩니다.

일반적으로 해당 오류 상태를 확인 하지 않을 만한 충분한 이유가 없는 경우 가 있습니다. 내가 오류 상태를 확인하지 않기 위해 생각할 수있는 유일한 이유는 실패하면 의미있는 일을 할 수 없을 때입니다. 항상 실행 가능한 옵션이 하나 있기 때문에 이것은 매우 어려운 바입니다.