오류 코드를 어떻게 할당합니까?

13

중간 규모의 프로젝트를 개발할 때 어떻게 오류 코드를 식별, 생성 및 유지합니까?

나는 내 삶에서 간단하고 깨끗한 방법을 생각할 수 없습니다. 내 아이디어 중 일부는 클래스 이름과 메소드 이름을 정수 문자열로 변환하지만 메소드 이름과 클래스 이름이 변경 될 수 있다는 사실 위에 오랫동안 사용자에게 표시하는 방법입니다. 다른 사람들은 증가하는 로그 시스템을 사용하고 있습니다 (즉, 새 오류 메시지를 만들 때 마지막 오류 메시지 ID에 1을 추가하십시오). 그러나 그것은 완전히 조직되지 않은 것입니다.

좀 더 구체적으로 말하면 다음과 같은 오류 코드에 대해 이야기하고 있습니다.

Error 401 Unauthorized.

error-messages

— ahodder
소스

1

오류 코드? "마법의 숫자"처럼? 예를 들어 ... ERROR 001. 그런 다음 목록으로 이동하여 ERROR 001을 읽는다는 것은 bla bla bla ...를 의미합니다.

— wleao

@wleao-예시 르. 나는 그것을 포함하도록 내 질문을 편집 할 것입니다. 감사합니다.

— ahodder

:이 읽기 en.wikipedia.org/wiki/Magic_number_%28programming%29

— wleao

질문에서 편집 한대로 그들이 어떻게 http를 사용하는지 살펴보십시오. 마법의 숫자를 사용하는 것이 좋은지 모르겠습니다. 그러나 정말로 기꺼이 원한다면 개념을 따르십시오. 예를 들어, 오류 분류법이 있습니다 (그렇습니까?).

— wleao

@wleao-아직은 아니지만 당신과 Péter Török 덕분에 나는 분명히 하나를 만들 것입니다. :)

— ahodder

16

아니.

오류 코드는 시대에 뒤떨어지기 때문에 출력이 실제로 어려웠고 비용이 많이 들었던 예전 시대에서 비롯된 것입니다. 오류 상태를 알리는 유일한 방법은 전면 패널 표시등을 통해 발생했을 수 있습니다. pdp11 / 70 전면 패널

요즘에는 거의 모든 주류 언어에 기본적으로 제공되는 성숙한 예외 처리 기능이 있습니다. 사용해. 작업 할 수있는 정보를 사용자에게 제공하십시오. 기술적 인 blah-blah로 그들을 귀찮게하지 말고, 무엇이 잘못되었는지, 그리고 그것에 대해 무엇을 할 수 있는지 대략 알려주십시오. 로깅의 경우 예외에 설명적인 이름을 지정하고 이름을 기록하십시오. 더 쉽게 기억하고 grep 또는 유사한 검색 도구를 사용하여 쉽게 찾을 수 있습니다.

물론 임베디드 시스템이나 네트워크 프로토콜과 같이 출력이 여전히 어렵고 비용이 많이 드는 상황에 대해 프로그래밍하는 경우는 예외입니다. HTTP는 여전히 효율적으로 구문 분석하기가 매우 쉽기 때문에 숫자 응답 코드를 사용합니다. 일부 상황에서는 첫 번째 숫자 만 읽으면 이미 충분히 알 수 있으며 나머지 패킷은 버릴 수 있습니다.

— tdammers
소스

이해하기 쉽고 자세한 답변을 주셔서 감사합니다.

— ahodder

당신의 비유는 당신의 주장과 완벽하게 일치합니다. 나는 PDP-11에 대해 영원히 읽었습니다. 그러나 이것은 실제로 내가 본 첫 번째 것입니다. 감사.

— Mike Owens

2

코드 내부에서 오류 코드를 처리하고 그다지 오래되지 않았습니다.

— JeffO

@Jeff : 에러 코드로 할 수있는 모든 것 또한 예외와 함께 할 수 있습니다. 예외를 사용하여 오류 코드를 모방하려는 경우 오류 코드를 반환하는 대신 throw하고 E_OK (또는 OK 응답이 무엇이든)와 반환 값을 비교하는 대신 catch하면됩니다. 그러나 공정하게 말하면 C에는 예외가 없으며 longjump는 편리하지 않으므로 C를 수행하는 경우 다소 변명됩니다.

— tdammers

@Mike : 이미지는 PDP-11 시리즈의 Wikipedia 기사에서 가져온 것입니다. 그것이 찾기 쉽지 않으면 나는 무엇인지 모른다.

— tdammers

6

HTTP 와 같은 일반적인 프로토콜로 오류 / 상태 코드가 구성되는 방법을 확인해야합니다 . 서로 다른 유형의 상태 / 오류에 대해 서로 다른 범위를 예약합니다. 이를 통해 사용자는 알 수없는 상태 코드를 쉽게 식별 할 수 있고 개발자는 이전에 처리되지 않은 새로운 종류의 오류에 대한 코드를 할당 할 수 있습니다.

— 페테르 토 ö
소스

답에 분류법을 추가하십시오. 오류를보다 쉽게 관리하고 유지 관리 할 수 있습니다.

— wleao

3

죄송합니다. 왜 오류 코드를 사용합니까?
프로그램 을 복구 할 수없는 경우 예외를 잡아서 기록하고 보고서를 보내도록 제안하십시오 .

언어가 예외를 지원한다고 가정합니다.

버그 수정에 도움이 될 수 있는 유일한 관련 정보 는 오류 코드가없는 스택 추적 입니다. (또한 오류 보고서에 오류 코드를 사용하고 사용자의 얼굴에 넣지 않기를 원한다고 가정합니다.)

— 단
소스

그것은 매우 사실입니다.하지만 그렇게하는데 사용자에게 무엇을 말합니까? 나는 그들이 함께 모여서 응용 프로그램이 그냥 죽거나 설명이나 연기 할 것이 없다면 생생하게 될 것이라고 확신합니다.

— ahodder

6

나는 여기에 혼란스러워하는 세 가지 다른 것이 있다고 생각합니다. 첫 번째는 HTTP와 같이 소프트웨어에서 소프트웨어로 사용되는 코드입니다. 두 번째는 사용자가 오류 보고서에서 사용할 수있는 코드 (사고 번호)입니다. 마지막은 사용자에게 표시 할 수있는 메시지입니다. 그것들을 별개의 것으로 간주하는 것이 도움이 될 수 있습니다.

— Darien

2

백엔드 애플리케이션을 빌드 할 때 오류 코드를 사용해야하는 큰 이유 중 하나입니다. 클라이언트 프로그램이 오류 메시지 나 스택 추적보다 코드를 해석하고 응답하는 것이 훨씬 쉽고 우아합니다. 모든 오류가 버그에서 나오는 것은 아닙니다.

— Kaypro II

1

예외는 바로 잡기가 매우 어렵다! programmers.stackexchange.com/questions/97874/…의

— Coder

@ 코더 : 귀하의 예는 예외를 남용합니다. 당신은해야 당신이 슬로우 기대 잡을 . 대부분의 메소드는 단 하나의 예외도 발생하지 않아도됩니다. 처리 할 대상을 결정 하는 것은 전적으로 프로그래머의 책임 이며 , 올바르게 처리하기가 어렵다는 데 동의합니다 .

— Dan

2

절차 적 맥락 (C)을 가정하겠습니다. 객체가있는 경우 예외 여부에 관계없이 일반적으로 오류 객체가 좋습니다.

각 모듈에 대해 로컬 오류 코드를 사용해야합니다. 라이브러리의 경우 숫자 1, 2 등으로 오류 코드를 나열하는 특수 헤더를 가질 수 있습니다 (또는 원하는 경우 -1, -2). 이러한 코드 중 하나를 항상 반환해야합니다 (예 : errno자신의 코드로 번역) . 여러 계층의 모듈이있는 경우 각 단계에서 변환하십시오 (또는 더 깊은 오류의 범위를 미리 정의하십시오 (예 : 값 1001-1050은 다른 모듈의 값임)).

코드를 문자열로 변환하는 수단을 제공하는 것도 중요합니다. 좌절 만 초래하는 코드 만보고해서는 안됩니다. 실제로 응용 프로그램의 거의 모든 코드에는 문자열 변환 기능이 있어야합니다. 예를 들어 libc에는 일반적으로 strerror및 strsignal이 있지만 슬프게도 부족 strwaitstatus합니다.

— 요한슨 당
소스

환상적인 세부 사항, 감사합니다. 실제로 도움이됩니다.

— ahodder