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

3줄 요약

• 오류는 클래스 기반 예외로 알리고, 정상적인 조회 결과까지 예외로 처리하지 않아요.

• 호출자가 처리할 수 있는 상황인지에 따라 예외 범주를 선택해요. 덤프는 복구가 불가능한 상황에 신중히 사용해요.

• 다른 컴포넌트의 예외는 내 기능에 맞는 예외로 변환하되 previous로 원인을 남겨요.

어떤 상황에서 쓰나요

오류를 반환 코드로 알릴지, 예외로 알릴지 정하기 어려울 때가 있어요. 이번 글에서는 Clean ABAP이 클래스 기반 예외를 권하는 이유와 예외 종류를 고르는 기준을 알아봐요. 다른 컴포넌트의 예외를 처리해 호출자에게 전달하는 방법도 살펴봐요.

다른 컴포넌트의 오류를 업무에 맞는 예외로 바꾸더라도 원인까지 버리면 진단이 어려워집니다. 아래 그림의 연결 고리처럼 previous로 원래 예외를 남겨 두세요.

핵심 내용

메시지는 찾기 쉽게. 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