C #에서 엔터프라이즈 프로젝트에 대한 오류 코드 패턴을 만드는 모범 사례 [닫기]

많은 중소기업과 기업에 배포 될 엔터프라이즈 프로젝트를 진행하고 있습니다.
이 프로젝트에 대한 지원은 어려움을 겪고 있으므로 HTTP 상태 코드와 같은 오류에 대한 코딩 패턴을 만들고 싶습니다 . 이를 통해 헬프 데스크 직원은 가능한 빨리 문서를 참조하고 문제를 해결할 수 있습니다.

이를위한 모범 사례와 권장 사항은 무엇입니까?
이 작업을 수행하는 데 도움이 될 것입니다.

c# programming-practices error-handling enterprise-development

— 푸야
소스

가능한 답변이 너무 많거나 좋은 답변이이 형식에 비해 너무 깁니다. 답변 세트를 좁히거나 몇 단락에서 답변 할 수있는 문제를 분리하려면 세부 정보를 추가하십시오. 그리고 당신은 지금까지 무엇을 시도했습니다.

— Ben McDougall

비즈니스 구성 방식에 따라 다릅니다. C #에서는 항상 사용자에게 StackTrace를 메일로 보내거나 오류 메시지 세부 정보에서 복사 / 붙여 넣을 수있는 가능성을 항상 제공했습니다 (보안 요구 사항은 엄격하지 않았습니다).

— 팔콘

답변:

오류 코드와 오류 반환 값에는 차이가 있습니다. 오류 코드는 사용자 및 헬프 데스크를위한 것입니다. 오류 반환 값은 코드에 오류가 발생했음을 나타내는 코딩 기술입니다.

오류 반환 값을 사용하여 오류 코드를 구현할 수는 있지만 이에 대한 조언을 드리겠습니다. 예외는 오류를보고하는 현대적인 방법이므로 오류 코드를 포함하지 않아야 할 이유가 없습니다.

이것이 내가 구성하는 방법입니다 (2-6 점은 언어에 구애받지 않습니다).

추가 ErrorCode특성 과 함께 사용자 정의 예외 유형을 사용하십시오 . 메인 루프의 catch는이 필드를 일반적인 방식으로보고합니다 (로그 파일 / 오류 팝업 / 오류 응답). 모든 코드에서 동일한 예외 유형을 사용하십시오.
1에서 시작하지 말고 선행 0을 사용하지 마십시오. 모든 오류 코드를 같은 길이로 유지하면 잘못된 오류 코드를 쉽게 찾을 수 있습니다. 일반적으로 1000에서 시작하면 충분합니다. 어쩌면 사용자가 명확하게 식별 할 수 있도록 선행 'E'를 추가 할 수 있습니다 (특히 지원 데스크에서 사용자에게 오류 코드를 발견하는 방법을 지시해야 할 때 유용함).
모든 오류 코드 목록을 유지하되 코드 에서이 작업을 수행하지 마십시오 . 새 코드가 필요할 때 쉽게 편집 할 수있는 개발자 용 위키 페이지에 짧은 목록을 유지하십시오. 헬프 데스크에는 자체 위키에 별도의 목록이 있어야합니다.
오류 코드에 구조를 적용하지 마십시오. 분류하기 어려운 오류가 항상 있으며 오류가 45xx 그룹 또는 54xx 그룹에 있는지 여부를 몇 시간 동안 논의하고 싶지 않습니다. 실용적 입니다.
코드의 각 던지기에 별도의 코드를 할당하십시오. 같은 원인이라고 생각하더라도 헬프 데스크는 상황에 따라 다른 작업을 수행해야 할 수도 있습니다. 사용자가 자신이 잘못한 것을 고백하도록하는 것보다 위키에 "E1234 : See E1235"가있는 것이 더 쉽습니다.
헬프 데스크에서 요청하면 오류 코드를 분할하십시오. if (...) throw new FooException(1234, ".."); else throw new FooException(1235, "..");코드 의 간단한 줄은 헬프 데스크에 30 분을 절약 할 수 있습니다.

오류 코드의 목적은 헬프 데스크의 삶을 편하게 만드는 것임을 잊지 마십시오 .

— 소 코드
소스

나는 이것을 개인적으로 한 적이 없지만 종종 "상관 ID"뿐만 아니라 사용자에게 표시되고 기록되는 오류 인스턴스 별 guid를 보게됩니다. 이렇게하면 대략적인 시간과 오류 코드보다 로그에서 정확한 오류 발생을 더 쉽게 찾을 수 있습니다.

— xdhmoore

헬프 데스크의 사람이 읽을 수있는 오류 코드와 개발자의 오류 인스턴스 ID로 사용할 수 있도록 상관 관계 ID 내에 오류 코드를 포함시키는 방법이 있다고 생각합니다.

— xdhmoore

내 패턴은 매우 비슷합니다. 그러나 "E"대신 앱 파트를 추가했습니다. 우리의 문서 프레임 워크는 예를 들어 Doc1234메인 앱이 가질 수있는 시간이 있습니다 IrS1234. 따라서 헬프 데스크 동료는 사용자를 돕는 데 매우 빠릅니다.

— Matthias Burger

먼저 오류가 발생할 수 있고 사용자가 볼 수있는 영역을 분리해야합니다. 그런 다음 문서화 할 수 있습니다. 간단합니다.

글쎄, 이론 상으로는 간단합니다. 실제로 오류가 발생할 수있는 곳에서 오류가 발생할 수 있으며,이를보고하면 멋진 코드를 로깅, 예외 발생 및 처리, 반환 값 전달의 괴물로 바꿀 수 있습니다.

그런 다음 2 단계 접근 방식을 권장합니다. 먼저, 로트 및 로트를 로그, 로그하는 것입니다.

두 번째는 주요 구성 요소 및 해당 인터페이스를 결정하고 이러한 구성 요소가 발견 할 수있는 주요 오류 사례를 정의하는 것입니다. 그런 다음 이러한 오류 중 하나가 발생하면보다 눈에 잘 띄는 방식으로 로그인 할 수 있습니다 (오류를 내부적으로 처리하는 방법은 사용자에게 달려 있음) -예외 또는 오류 코드는 여기서 차이가 없습니다.) 그러면 사용자는 일반적으로 오류를보고 자세한 정보를 보려면 로그로 이동합니다.

웹 서버 및 http 오류 코드 예제에도 동일한 방법이 사용됩니다. 사용자가 404를보고이를 지원한다고보고하면 진행 상황, 방문한 페이지,시기 및 기타 정보가있는 곳에서 자세한 정보를 로그에서 확인할 수 있습니다. DB, 네트워크 또는 응용 프로그램에 있어야합니다.

— bj
소스

나는 설명적인 이름과 명확한 메시지로 사용자 정의 예외를 처리하고 던질 것입니다. 오류 코드를 전달하고 해석하는 지원을 빌드하는 것보다 언어의 기존 예외 인프라를 사용하는 것이 훨씬 쉽습니다.

— 스테판 빌리 엣
소스

이 답변을 1에서 0으로 하향 조정 한 사람에게 최소한 이유를 제시해 주신 것에 감사드립니다.

— Stefan Billiet

내가 downvoting하지는 않았지만 (중요하지는 않지만) 언어에서 반환 값에 대한 기존 지원이 있다고 생각합니다.

— gbjbaanb

그것은 나에게 중요하다. 내가 틀렸다면, 내가 배울 수 있도록 알고 싶습니다 :-p 반환 값에 대한 기존 지원은 무엇을 의미합니까? 일반 반환 값을 오류 코드와 구별하기 위해 배관을 작성하지 않아도됩니까? 시스템 경계에서 예외를 오류 코드로 변환하는 것은 한 가지 일이지만 시스템 내에서 오류를 저글링하는 것은 일반적으로 권장되는 사항입니다. 나는 Pragmatic Programmer가 이런 종류의 것들을 언급한다고 생각합니다.

— Stefan Billiet '

모든 경우에 예외가 좋은 메커니즘은 아니지만 오류를 사용하기로 결정한 경우 모든 호출에 out param을 추가하거나 중요한 호출이 모두 코드를 반환하도록 할 수 있습니다. 그렇게하기 위해 미리 결정하면 황금색입니다. 실용적으로 경계에 두 개의 반환 오류 코드가 혼합되어 단일 언어로 잠겨 있지 않고 내부적으로 예외를 사용하게됩니다.

— gbjbaanb

나는 당신에게 투표하지 않았습니다 (쉽게 가져 가십시오. 그렇지 않으면 모든 사람들이 이것을 반복해야합니다 :). 서비스 데스크에서 근무했거나 전화를 거는 경우 오류 메시지보다 짧은 번호로 통신하는 것이 훨씬 쉽습니다. 오류 메시지는 구두로 전달 될 때 변경됩니다.

— Codism