시스템 오류 노출 / 허용 / 복구에 대한 설계 패턴 / 접근법 권장, 예외 처리 (예 : Java, C ++, Perl, PHP)

시스템 오류 노출 / 허용 / 복구, 예외 처리 (Java, C ++, Perl, PHP)에 디자인 패턴 / 접근법을 추천 할 수 있습니까?

일부 오류가보고되어야합니다.

일부 오류는 내부적으로 처리 할 수 ​​있습니다 (재시도 또는 중요하지 않음 (무시 될 수 있음)).

코드를 잡기 위해 어떻게 코드를 구성합니까?

그러나 모든 오류를 기록해야합니다.

어떤 모범 사례가 있습니까?

영향을받는 구성 요소를 완전히 테스트 할 수있는 시뮬레이션을 위해?

몇 가지 현대적인 프로그래밍 언어에 적용 할 수있는 일반적인 비 프로그래밍 언어 관련 질문이지만 Java, C ++, PHP 및 Perl의 패턴, 접근 방식 및 철학의 예시를 환영합니다.

(또한 stackoverflow에서 요청했습니다 : /programming/7432596/recommend-a-design-pattern-approach-to-exposing-tolerating-recovering-from-system 이지만 프로그래머에게도 요청해야한다고 생각했습니다. 프로그래머 Q & A가 더 넓은 소프트웨어 / 프로그래밍 문제를 다루는 반면 스택 오버 플로우는 기술적 구현 IMHO에 관한 것입니다).

빠른 실패 는 훌륭한 디자인 방식이며 패턴으로 계산 될 수 있습니다. http://en.wikipedia.org/wiki/Fail-fast

또한 유용한 여러 가지 원칙을 발견했습니다.

• 각 기능 / 모듈에 대한 인터페이스의 일부로 예외를 고려하십시오. 즉, 문서화하고 해당되는 경우 언어가 지원하는 경우 확인 된 예외를 사용하십시오.
• 실패를 퍼지하지 마십시오. 실패한 경우 진행 방법을 "가정"하려는 시도를 계속하지 마십시오. 예를 들어 null 경우에 대한 특수 처리는 종종 코드 냄새입니다. 메서드에 null이 아닌 값이 필요한 경우 null이 발생하면 즉시 예외를 throw해야합니다 (NullPointerException 또는 더 설명적인 IllegalArgumentException).
• 예외적 인 경우와 일반적인 경우에 대한 단위 테스트를 작성하십시오. 때로는 이러한 테스트를 설정하기가 까다로울 수 있지만 시스템이 장애에 견고하다는 것을 확신 할 때 가치가 있습니다.
• 오류가 포착되고 처리 된 지점에 기록하십시오 (오류가 기록 될 정도로 심각하다고 가정). 그 이유는 원인을 이해하고 오류를 처리 할 수있는 방법이 있었으므로 로그 메시지를 의미있게 만들 수 있기 때문입니다.
• 예상치 못한 상황 / 실패에 대해서만 예외를 사용하십시오. 함수가 실제로 예상되는 방식으로 "실패"하는 경우 (예 : 더 많은 입력을 사용할 수 있는지 폴링하고 아무것도 찾지 않는 경우) 정상적인 응답 ( "입력 할 수 없음")을 반환하고 예외를 발생시키지 않아야합니다.
• 정상적으로 실패 (Steven Lowe에게 신용!) -가능하면 종료하기 전에 정리하십시오. 정리는 명확성과 논리적 일관성을 위해 리소스가 커밋 된 수준과 동일한 수준에서 수행되어야합니다.
• 실패해야하는 경우 큰 소리로 실패 하십시오. 코드의 어떤 부분도 처리 할 수 ​​없었던 예외 (즉, 잡히지 않고 처리되지 않은 최상위 수준으로 여과 됨)는 즉각적이고 시끄러 우며 눈에 띄는 오류로 인해주의를 기울여야합니다. 나는 일반적으로 프로그램이나 작업을 중단하고 전체 예외 보고서를 System.out에 씁니다.

Java 및 .NET에서 예외로 작업하고 예외를 잡는 방법 /시기 / 이유에 대한 많은 기사를 읽은 후 잠재적 예외가 발생할 때마다 다음 단계를 거쳐야했습니다. 예외는 발생하지 않더라도 (Java)를 잡아야합니다 (한숨 ...). 그리고 그것은 적어도 나를 위해 작동하는 것 같습니다.

1. 그 예외로 로깅 할 수있는 것을 제외하고 유용한 것이 있습니까? 대답이 예이면 해결 방법 코드를 작성하고 해결 방법으로 예외가 발생할 수있는 경우 2로 이동하십시오.
2. 예외를 런타임 예외로 감싸서 던져서 3으로 이동하십시오.
3. 가능한 데이터베이스 / 프로세스 트랜잭션이 시작된 상위 레벨 클래스에서 예외를 포착하고 트랜잭션을 롤백하고 예외를 다시 발생 시키십시오.
4. 최상위 클래스 (트랜잭션이 시작된 클래스 일 수 있음)에서 slf4j ( 예 : log4j 와 결합 된 ) 또는 log4net 과 같은 로깅 프레임 워크를 사용하여 예외를 로깅하십시오 . 가능하면 응용 프로그램 개발자로 구성된 메일 그룹에 예외를 직접 전자 메일로 보내십시오.
5. GUI가있는 경우 가장 사용자 친화적 인 방식으로 문제의 원인을 나타내는 오류 메시지를 표시하십시오. 예외 / 스택 추적을 표시하지 않으면 사용자는 신경 쓰지 않으며 NullPointerException인지 알 필요가 없습니다.

또한 데이터 오류로 인해 복잡한 처리를 실행할 수 없을 때 의도적으로 "비즈니스"예외 ( "예외"클래스를 확장하여 생성 한 새로운 예외)를 던지는 단계 0을 추가해야 합니다. 분석 중에 예외 사례로 확인 된 것으로 알려져 있습니다.

벌목 부분을 제외하고, 나는 "mikera"의 글에 전적으로 동의합니다. 예외를 한 번만 기록 해야한다고 덧붙 입니다.

또한 작성중인 내용이 API / 프레임 워크 인 경우 나열된 단계가 다를 수 있습니다 . 거기에서 개발자가 실수를 이해하도록 돕기 위해 잘 설계된 예외를 던지는 것이 필수적입니다.

예외 테스트의 경우, 모의 객체를 사용하면 클래스가 "한 가지 일을하는 하나의 클래스"모범 사례를 존중하는 경우 예외 여부와 상관없이 거의 모든 것을 테스트 할 수 있어야합니다. 또한 개인적으로 가장 중요하지만 숨겨진 방법을 "개인"대신 "보호"로 표시하여 너무 번거 로움없이 테스트 할 수 있도록합니다. 그 외에도 예외 테스트는 간단합니다. 예외를 유발하고 예외를 잡아서 예외를 "예상"하십시오. 예외가 발생하지 않으면 단위 테스트 사례 오류가있는 것입니다.

외부 요인에 대해 걱정하지 말고 올바른 방법으로 물체를 만드십시오. 예외를 이용하기로 선택한 경우, 객체 가 무언가 실패하면 예외를 발생 시킵니다.

모든 객체가 올바르게 작동하면 디자인에서 오류 처리 책임 계층을 명확하게 파악할 수 있습니다.