---
kind: REFERENCE
slug: messaging-kafka-share-experimental-f04
title: 구성 오류는 한 예외 타입과 안정 코드로 보고한다
topic: runtime-contract-correctness
project: clean-architecture-backend-template
status: 게시 전
sourceRevision: 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916
rootTreeNode: reference:messaging-kafka-share-experimental-f04
verifiedOn:            # 이 기록은 이번 회차에 실행 확인을 하지 않았다
source:
  - analysis/messaging/messaging-kafka-share-experimental.md#L494
---

# 구성 오류는 한 예외 타입과 안정 코드로 보고한다

## 관계

- **"등록"이 아무것도 등록하지 않고 성공을 반환한다**
  이 규칙의 근거는 같은 분석 리프의 판정이 소유한다.

## 목적

같은 시작 시점에 같은 종류의 설정 오류를 거절하면서 한쪽만 FailureDescriptor 를 갖게 되면, 운영자가 받는 두 실패 중 하나에만 코드와 카테고리가 붙는다.

## 규칙

1. 같은 검증기 안의 거절들이 같은 예외 타입인지 본다
   KafkaShareProfileValidator.java:31-40 에서 !enabled 는 MessagingCapabilityUnavailableException(안정 코드 KAFKA_SHARE_DISABLED)이고, orderingScope != NONE 은 IllegalArgumentException(코드 없음)이다.

2. 안정 코드가 없는 거절을 찾아 코드를 준다
   코드가 없으면 그 실패는 문자열로만 식별된다.

3. 같은 가족 안에서 갈라진 사례를 함께 본다
   messaging-security 의 MessageSecurityValidator 는 전부 IllegalArgumentException 이고 BrokerTlsPolicy 는 전부 MessagingConfigurationException 이다. 같은 형태의 분기가 이미 두 곳에 있다.

## 적용 조건

시작 시점에 설정을 거절하는 검증기 전부. 특히 한 클래스가 여러 규칙을 검사하는 자리.

## 예외

플랫폼 예외 계층이 닿지 않는 프레임워크 경계에서는 표준 예외가 불가피할 수 있다. 이 검증기는 그 경계가 아니다.

## 예시

KafkaShareProfileValidator.java:31-40 의 두 throw 문. 확인 방법은 그 둘을 나란히 대조하는 것이다.