오류 처리
실패, 해당 소유자, 그리고 실패 후에도 안전하게 유지되는 대상을 정의합니다. 이는 체크리스트가 아닌 지침입니다.
정형화된 구조적 실패
예상되는 실패에는 선언된 유형, 안정적인 판별자, 그리고 처리에 관련된 세부 정보가 필요합니다. 프로젝트의 오류 규칙을 재사용하고, 원인을 보존하며, 기계 식별자와 표시 텍스트를 분리하십시오. 메시지 구문 분석을 통해 처리를 라우팅하지 마십시오. 완전성 검사 실패와 같은 예상치 못한 결함은 단순 오류로 남을 수 있습니다. 격리는 절대 이를 성공으로 바꾸지 않아야 합니다.
포착, 복구, 또는 중단
각 실패에 대해, 처리 및 보고 소유자, 격리, 그리고 보장 사항을 소유 API 문서에 정의하십시오: 어떤 불변 조건이 유효한지, 부작용이 없는지, 부분적인지, 커밋되었는지, 알 수 없는지, 그리고 정리 책임이 누구에게 있는지. 백그라운드 작업은 이러한 의무를 유지합니다.
포착은 예외 전파를 제한할 뿐, 변이는 제한하지 않습니다. 영향을 받은 상태의 소유자만이 안전한 계속 실행을 확립할 수 있습니다. 그렇지 않으면 종속 작업을 중단하고, 유효하지 않은 상태나 인스턴스를 폐기하거나, 에스컬레이션하십시오. 단순한 로깅은 복구가 아닙니다. 재시도에는 안전한 반복, 취소, 그리고 명시적인 소유자가 필요합니다. 유한한 작업에는 예산이 필요하고, 지속적인 감독에는 생명주기 소유권과 관찰 가능한 성능 저하가 필요합니다.
지역화되고 실행 가능하며 가시적인 보고서
모든 최종 보고서는 읽기 쉬운 요약, 영향을 받은 작업, 그리고 안전한 다음 조치를 포함해야 합니다. 수신 애플리케이션의 로케일 메커니즘을 통해 지역화하십시오(존재하는 경우). 다른 진단은 기존의 출력 언어를 사용합니다. 민감한 내부 세부 정보를 사용자 대상 텍스트에 포함시키지 마십시오.
신뢰할 수 없는 상태나 알 수 없는 결과는 UI 또는 기본적으로 활성화된 접근 가능한 로그를 통해 가시적이어야 합니다: 영향, 불확실성, 시스템이 수행한 작업, 그리고 안전한 다음 단계를 보고하십시오. 지속적으로 유효하지 않은 상태는 지속적인 가시성이 필요합니다. 그 뒤에 있는 보장 없이 성공, 롤백 또는 안전한 재시도를 주장하지 마십시오. 실패 보고 자체에는 독립적인 대체 수단이 필요합니다.
단순히 예외가 포착되었는지가 아니라 결과 상태와 가시적인 결과를 검증하십시오.
기반
Meyer, Object-Oriented Software Construction (1997): 계약과 불변 조건. Sutter, Exceptional C++ (1999): 예외 안전성 보장. Armstrong, 소프트웨어 오류가 있는 상태에서 신뢰할 수 있는 분산 시스템 만들기 (2003): 격리와 감독.