오류 확인 및 처리를 개선하려면 어떻게해야합니까?

최근에 나는 올바른 점검이 무엇인지, 그리고 적절한 방법이 무엇인지 이해하기 위해 고심하고 있습니다.

이것에 관한 몇 가지 질문이 있습니다.

오류 (잘못된 입력, 잘못된 상태 등)를 확인하는 올바른 방법은 무엇입니까? 오류를 명시 적으로 확인하거나 최종 코드에서 최적화 할 수있는 assert와 같은 함수를 사용하는 것이 더 낫습니까? 어쨌든 대부분의 상황에서 실행해서는 안되는 많은 추가 코드가있는 프로그램을 어수선하게 검사하고 싶습니다. 대부분의 오류는 중단 / 종료 실패로 끝나지 않습니다. 왜 명시적인 검사로 함수를 어지럽히기만하면 중단됩니까? 나는 어설 션 대 명시 적 오류 검사를 찾았으며 언제해야 할지를 진정으로 설명하지 못했습니다.

대부분의 경우 '어설 션을 사용하여 논리 오류를 확인하고 명시 적 검사를 사용하여 다른 오류를 확인하십시오'라고 말합니다. 이것은 우리를 아주 멀리 가지 않는 것 같습니다. 이것이 가능하다고 말할 수 있습니까?

Malloc returning null, check explictly
API user inserting odd input for functions, use asserts

이것이 오류 검사에 더 좋을까요? 다른 무엇을 할 수 있습니까? 저는 '전문적인'코드를 개선하고 더 잘 작성하고 싶습니다.

차이점을 알려주는 가장 쉬운 방법은 오류 조건이 컴파일 타임에 발생하는지 런타임에 발생하는지 확인하는 것입니다. 문제가 어떻게 든 함수를 잘못 사용하는 프로그래머라면 문제에주의를 기울 이도록 주장하십시오. 그러나 수정 프로그램이 호출 코드로 컴파일되면 더 이상 검사에 대해 걱정할 필요가 없습니다. 메모리 부족 또는 최종 사용자 입력 불량과 같은 문제는 컴파일 타임에 해결할 수 없으므로 체크 인 상태로 두십시오.

100 % 미만 언제든지 (이 마지막 확인 후 변경되었을 수 있음)에서 확인 아무것도 할 당신의 명령을 실행합니다. 또한 개발 중에도 자신을 믿지 마십시오! ;-)

Okokok ... "anything"은 비정상적인 중단을 유발 하거나 응용 프로그램 / 시스템이 수행 할 수 없는 작업을 수행 할 수있는 항목을 검사하는 것으로 읽습니다 .

진지하게 말하면 마지막 문장의 마지막 부분은 주요 문제를 지적하기 때문에 필수적입니다.

당신은 안정적인 시스템을하지 시스템이 무엇을해야하는지에 대한 주요 관심사를 구축 할 수 있지만, 무엇을해야 치료 걸릴 한 요구를 같은 필수 작업을 수행 할 수 있도록하려면 없습니다 수행을하더라도 그것은 "클러 당신의 암호".

오류 처리의 요점은 문제를 파악하는 방법과 방법이 아닙니다. 그것에 대해 배우고 나면 더 많은 일을합니다 .

우선-하위 메서드에서 반환 된 단일 오류가 반환되는 이유가 없다고 말할 수는 없습니다. 그리고 오류와 예외는 반환 값 또는 모든 시도 / 캐치 이상입니다.

1. 던지고 잡는 것만으로는 충분하지 않습니다.
   이것을 참조하십시오 : 저자는 단지 잡는 것만으로 잠재적으로 예외를 억제하고 손상을 취소하기에 충분하지 않으면 코드를 그대로 두는 것보다 나쁘다고 설명합니다. 마찬가지로 파일 열기 또는 읽기 오류가있을 때 "log"문을 작성하면 이유를 찾는 데 도움이 될 수 있지만 프로그램이 종료 될 때 데이터가 손상 될 수 있습니다! 시도 / 캐치 가 많다고 말하는 것만으로는 충분 하지 않습니다. 그들이 실제로하는 일을 아는 것이 더 중요합니다!

2. 시도와 캐치를 남용하지 마십시오.
   때로는 게 으르거나 순진한 프로그래머가 충분한 시도 / 잡기를 작성한 후에는 업무가 끝났다고 생각합니다. 종종 전체를 버리는 것보다 시정 조치를 적용하고 재개하는 것이 가장 좋습니다. 이 작업을 수행 할 수 없으면 어느 수준으로 돌아 가야하는지 결정해야합니다. 상황과 심각도에 따라 캐치 중첩을 신중하게 설계해야합니다. 예를 들어- 이것 과 이것을 참조하십시오

3. 담당자를 정의하십시오.
   가장 먼저해야 할 작업 중 하나는 루틴 자체에 제공된 입력이 허용 할 수없는 (또는 지금까지 처리되지 않은) 시나리오인지 또는 환경 (시스템 문제, 메모리 문제 등)으로 인한 예외인지 또는 이 상황은 알고리즘 결과로 인해 완전히 내부적으로 발생합니다. 모든 경우에-당신이 돌아가고 싶거나 취할 행동의 수준이 크게 다릅니다. 이 관점에서 나는 프로덕션에서 코드를 실행할 때 프로그램을 종료하기 위해 abort ()를 만드는 것이 좋지만 모든 작은 것은 아닙니다. 메모리 손상이나 메모리 부족을 발견하면 최선을 다한 후에도 죽을 것입니다. 그러나 입력에서 NULL 포인터를 받으면

4. 최상의 결과를 정의하십시오
   . 예외 상황에서 수행해야 할 모든 작업은 매우 중요합니다. 예를 들어, 미디어 플레이어가 사용자에게 재생할 전체 데이터가없는 것으로 판명되면 어떻게해야합니까?

   • 나쁜 부분을 건너 뛰고 좋은 일을 해낼 수 있는지 확인하십시오.
   • 이것이 너무 많이 발생하면 다음 노래로 건너 뛸 수 있는지 고려하십시오.
   • 파일을 읽을 수없는 것으로 판단되면 중지하고 표시하십시오.
   • 한편
   • 어떤 상태에서 플레이어가 사용자에게 POP-UP해야하는지
   • 언제 자체적으로 수행해야합니까?
   • 사용자에게 피드백을 요청하는 것을 "중지"해야하는 경우
   • 또는 구석에 눈에 거슬리지 않는 작은 오류 메모를 넣어야합니까?

   이 모든 것은 주관적이며 아마도 사소한 것보다 문제를 처리하는 방법이 더 많습니다. 위의 모든 사항은 예외의 깊이를 구축하고 이해해야하며 다른 시나리오를 발전시킬 수 있어야합니다.

5. 때로는 예외가 발생하기 전에 확인해야합니다. 가장 일반적인 예는 0으로 나누기 오류입니다. 이상적으로는 예외가 발생하기 전에 테스트해야합니다.이 경우에는 0이 아닌 가장 적절한 값을 설정하고 자살하기보다는 계속 진행하십시오!

6. 대청소. 최소한 이것은 당신이해야 할 일입니다! 함수가 3 개의 파일을 열고 네 번째 파일을 열지 못하면 첫 번째 3 개를 닫았을 필요는 없습니다. 이 작업을 위의 계층에 위임하는 것은 나쁜 생각입니다. 메모리를 청소하지 않고 떠나지 않기로 결정한 경우. 그리고 가장 중요한 것은 예외가 살아남더라도 정상적인 과정을 거치지 않았다는 사실을 더 높이 알리십시오.

다양한 계층 또는 계층 또는 추상화 측면에서 소프트웨어의 (정상적인) 기능을 보는 방식과 마찬가지로 심각도 및 예외가 발생하는 범위를 기준으로 예외를 분류해야하며 시스템의 다른 부분에 영향을 미치는 방식과 동일합니다. 최상의 방법으로 이러한 다른 예외를 처리하는 방법.

최상의 참조 : Code Craft 6 장- 다운로드 가능

디버그 빌드 중 오류 만 검사하는 것은 BAD IDEA (tm)이며, 릴리스에서 컴파일하면 재사용 가능한 변수를 스택에 오버레이하고, 가드 페이지를 제거하고, 트릭을 계산으로 계산하고, 무거운 관절염을 사전 계산 된 시프트로 대체합니다.

릴리스시 오류 검사를 사용하면 다음과 같은 간단한 방법을 사용할 수 있습니다.

if(somethinghitthefan)
     abort();

또한 베타 테스터 PC에서 응용 프로그램이 충돌하기 시작하면 버그를 무시하지 않을 매우 좋은 부작용이 있습니다.

이벤트 뷰어와 로그는에 비해 완전히 쓸모가 없습니다 abort().

수행 할 수있는 다양한 작업은
다음과 같습니다. 1. 온라인에서 많은 코드를 읽고 동화하고 어떻게 수행되는지 확인합니다.
2. 오류 영역을 찾는 데 도움이되는 일부 디버깅 도구를 사용합니다.
3. 부적절한 할당으로 인한 사소한 오류를 인식하고 구문 오류.
4. 찾기가 더 어려운 프로그램의 논리적 오류로 인해 일부 더 나쁜 오류가 발생합니다.이를 위해이를 찾아 내거나 더 복잡한 사람들이 사람들에게 말하거나 Stackoverflow , Wikipedia , Google 과 같은 리소스를 사용 하여 도움을 얻을 수 있습니다 사람들.