Clean ABAP ⑨ 오류 처리: 예외 종류 고르기와 던지기, 잡기

3줄 요약

• 반환 코드보다 클래스 기반 예외를 쓰고, 예외는 "정상적인 경우"가 아니라 "오류"에만 써요.

• 예외 종류는 CX_STATIC_CHECK(복구 가능), CX_NO_CHECK(복구 어려움), 덤프(프로그래밍 오류 수준) 순으로 심각도에 맞춰 골라요.

• 한 메서드는 한 종류의 예외만 던지고, 남의 컴포넌트 예외는 잡아서 내 예외로 감싸요.

어떤 상황에서 쓰나요

sy-subrc 와 RETURN 값을 줄줄이 검사하던 코드를 예외 기반으로 바꾸려 할 때, 또는 "이 경우에 예외를 던져도 되나? 어떤 예외 클래스를 쓰나?"를 팀에서 정해야 할 때 이 장이 기준이 돼요. 이번 회는 메시지, 반환 코드, 예외, 던지기, 잡기를 한꺼번에 다뤄요.

핵심 내용

메시지는 찾기 쉽게. SE91 의 사용처 검색에 걸리도록 MESSAGE e001(ad) INTO DATA(message). 처럼 써요. 변수가 필요 없으면 프라그마 ##NEEDED 를 붙여요. IF 1 = 2. MESSAGE e001(ad). ENDIF. 는 도달할 수 없는 코드이고 절대 참이 될 수 없는 조건이라 피해요.

예외를 반환 코드보다 먼저. RAISE EXCEPTION NEW cx_failed( ) 가 error_occurred = abap_true 보다 나은 이유는 네 가지예요.

• 메서드 시그니처가 깨끗해요. 결과는 RETURNING 으로, 오류는 예외로 따로 가요.

• 호출자가 바로 반응하지 않아도 돼요. 정상 흐름만 쓰고 CATCH 는 맨 끝이나 바깥에 둘 수 있어요.

• 예외는 속성과 메서드로 오류의 자세한 내용을 줄 수 있어요.

• 처리하지 않으면 문법 오류로 알려 줘요. 반환 코드는 아무도 모르게 무시될 수 있어요.

반환 코드를 써야 한다면(내가 관리하지 않는 함수나 레거시 호출) 실패가 새어 나가지 않게 IF response-type = 'E'. RAISE EXCEPTION ... 로 바로 예외로 바꿔요.

예외는 오류에만. "있나 없나"는 정상적인 경우이므로 예외가 아니라 RETURNING result TYPE abap_bool 로 답해요. 예외를 잘못 쓰면 읽는 사람이 무언가 잘못됐다고 오해하고, 예외는 만들 때 맥락 정보를 모아서 일반 코드보다 훨씬 느려요.

예전 방식(`EXCEPTIONS ... = 1`)은 쓰지 않아요. 클래스 기반 예외가 아닌 예외는 반환 코드와 똑같은 한계가 있어요.

던지기

• 애플리케이션마다 추상 상위 클래스를 만들어요(cx_fra_static_check, cx_fra_no_check). 내 예외를 한꺼번에 잡을 수 있고, 공통 기능을 넣을 수 있으며, ABSTRACT 라 설명 없는 오류를 그대로 던지는 걸 막아요.

• 한 메서드는 한 종류의 예외만 RAISING 해요. 호출자는 대부분 상황을 구분하지 못하거나 관심이 없어서 똑같이 처리하게 돼요. 구분이 필요하면 하위 클래스를 만들고(CATCH 를 구체적인 것부터), 상황이 아주 많으면 예외 안에 오류 코드를 상수 구조로 넣어요.

• CX_STATIC_CHECK: 예상할 수 있고 호출자가 합리적으로 처리할 수 있는 오류에 써요(사용자 입력 검증 실패, 대안이 있는 리소스 없음). 시그니처에 반드시 적고 잡거나 넘겨야 하므로 호출자가 놀라지 않아요. 이 선택은 ABAP 프로그래밍 지침과 같지만 《Clean Code》(검사하지 않는 예외 선호)와는 달라요.

• CX_NO_CHECK: 복구하기 어려운 심각한 상황에 써요(꼭 필요한 리소스를 못 읽음). 시그니처에 못 적어서 호출자는 예상 못 한 놀람을 겪지만, 어차피 할 수 있는 게 없는 경우예요. 다만 의존성 관리자처럼 테스트 리포트에서 잡아서 넘기고 싶을 수 있는 경우도 있다고 해요.

• CX_DYNAMIC_CHECK: 드물어요. 호출자가 예외가 일어날 수 있는지 완전히 통제할 수 있을 때 CX_STATIC_CHECK 대신 고려해요(예: 정적으로 타입이 정해진 변수를 cl_abap_math=>get_db_length_decs 에 넘길 때).

• 덤프: 프로그래밍 오류가 분명하거나 호출자가 아무것도 할 수 없다고 확신할 때만 써요. 7.53 이상은 RAISE SHORTDUMP TYPE cx_sy_create_object_error., 그 아래는 MESSAGE x666(general). 이에요.

• RAISE EXCEPTION NEW (7.52 이상)가 RAISE EXCEPTION TYPE ... EXPORTING 보다 짧아요. 다만 MESSAGE 추가 구문을 많이 쓰면 TYPE 형태를 유지하는 편이 나아요.

잡기. 다른 컴포넌트의 예외를 그대로 RAISING 으로 넘기면 데메테르 법칙을 어기게 돼요. 잡아서 내 예외로 감싸고 원인은 previous 로 붙여요.

TRY.
    generator->generate( ).
  CATCH cx_amdp_generation_failure INTO DATA(exception).
    RAISE EXCEPTION NEW cx_generation_failure( previous = exception ).
ENDTRY.

주의할 점

• CX_STATIC_CHECK 선호는 《Clean Code》의 권고와 반대라고 가이드가 스스로 밝히고, 이유는 별도 문서에 있다고 해요(저는 그 문서를 읽지 못했어요).

• 7.52 미만에서는 RAISE EXCEPTION NEW 를 쓸 수 없고, 7.53 미만에서는 RAISE SHORTDUMP 도 안 돼요. ECC 에서는 RAISE EXCEPTION TYPE ... EXPORTING 을 써야 해요.

• 기존에 sy-subrc 와 EXCEPTIONS 를 쓰는 표준 함수 모듈을 감쌀 때는 이 규칙을 그대로 쓰기 어려우니 위의 "반환 코드를 써야 한다면" 항목을 따르세요.

• 원문은 2019년 첫 공개, 2025년 3월 마지막 수정본이에요. 이 글은 읽고 정리한 것이고 코드를 직접 돌려 보지 않았어요.

원문 주소: https://github.com/SAP/styleguides/blob/main/clean-abap/CleanABAP.md#error-handling