표준화 된 오류 분류 및 처리

Question

오류/예외를 '우아하게'분류하고 처리하는 방법을 표준화해야합니다.

현재 오류를 오류로보고하는 프로세스를 사용하고 있습니다. 이 함수는 오류가 치명적이고 앱이 죽어야한다면 부울 진실을 반환합니다. 그렇지 않으면 거짓입니다. 프로세스의 일부로, 사용자에게 비주얼 피드백을 제외하고, 기능은 일부 심각도 수준의 로그 투자 오류도 있습니다.

Error-Number는 오류 유형을 설명하는 문자열 배열 (예 : '파일 액세스', '사용자 입력', '스레드 -creation', 'Network Access'등을 설명합니다. 심각도 코드는 이진 또는 0,1, 2 또는 4, 0 = 유익한 정보, 1 = user_retry, 2 = cancle_complete, 4 = cann_continue. Location-Info는 Module & Function이며, 엑스트라 인포는 매개 변수 및 로컬 변수 값입니다.

이것을 라이브러리에 넣고 모든 앱에서 재사용 할 수있는 표준 오류 처리 방법으로 만들고 싶습니다. 나는 주로 Linux에서 C/C ++를 사용하지만 다른 언어/플랫폼과 함께 결과 라이브러리를 사용하려고합니다.

• 아이디어는 오류 유형 배열을 확장하여 주어진 심각도 수준에 대한 기본 동작을 나타내는 것이지만, 이것이 조치를 취하고 사용자에게 옵션을 제공하지 않아야합니까?

• 또는 : 그러한 확장은 사용자가 선택 해야하는 옵션의 하위 배열이어야합니까? 이것의 문제점은 필수 옵션이 최종 사용자를 완전히 당황하게 할 수있는 프로그래밍 관련 옵션을 일반화한다는 것입니다.

• 또는 : Error -Lib 루틴을 사용하는 각 앱은 자체 오류 또는 기본 동작 배열을 따라 전달해야합니다. 그러나 이것은 라이브러리의 목적을 물리 칠 것입니다 ...

• 또는 : 각 앱에서 심각도 수준을 처리해야합니까?

또는 : 당신은 무엇을 제안합니까? 오류를 어떻게 처리합니까? 이것을 어떻게 개선 할 수 있습니까?

Answer 1

오류를 처리하는 방법은 실제로 응용 프로그램에 따라 다릅니다. 웹 애플리케이션은 데스크탑 응용 프로그램과 다른 오류 캐처 메커니즘을 가지고 있으며 둘 다 비동기 메시징 시스템과 크게 다릅니다.

즉, 오류 처리의 일반적인 관행은 처리 할 수있는 가장 낮은 수준에서 처리하는 것입니다. 이것은 일반적으로 응용 프로그램 계층 또는 GUI를 의미합니다.

나는 심각도 수준을 좋아합니다. 아마도 다른 오류 출력 제공 업체와 심각도 레벨 제공 업체가있는 플러그 가능한 오류 수집 라이브러리가있을 수 있습니다.

출력 제공 업체에는 LogginProvider 및 IgnoreErrorsprovider와 같은 것들이 포함될 수 있습니다. 심각도 수준은 일반적으로 발생하는 해당 유형의 프로젝트에 의해 결정되기 때문에 심각도 제공 업체는 아마도 각 프로젝트에서 구현 될 수 있습니다. (예를 들어, 연락처 관리 시스템보다 은행 응용 프로그램의 네트워크 연결 문제가 더 심각합니다).