Как class-based exceptions передают сбой через интерфейсы методов, где его обрабатывать и почему обработка не заменяет откат бизнес-операции.
3 мин чтения·База знаний
Ревизия 1Общие понятияЧастичное покрытиеКонтекст: CTX-GENERALдокументальная опора: недостаточно данных
Справочный материал. Контракты данных, архитектурные решения и ограничения применения. Источники приведены в материалах, где используются внешние основания.
Исключение в ABAP обозначает ситуацию, в которой обычное продолжение текущего пути выполнения не подходит. Для проектирования важны три вопроса: кто поднимает исключение, какие вызывающие методы обязаны его объявить или обработать и на каком уровне можно принять корректное решение.
Перехватываемое class-based exception представлено объектом класса исключения. Код поднимает его через RAISE EXCEPTION или THROW; обработчик задаётся блоком TRY ... CATCH ... ENDTRY. Если вызванный метод может передать исключение выше, его контракт должен это отражать через RAISING, либо вызывающий код должен обработать ситуацию.
Такой контракт помогает увидеть ошибки на границе вызова. Объявление RAISING не означает, что сбой уже обработан: оно лишь позволяет передать его следующему уровню. Если исключение не обработано, оно может завершить программу с runtime error. Поэтому обработчик размещают там, где доступны данные для осмысленного решения: преобразовать ошибку в понятный результат, добавить контекст или остановить операцию с диагностикой.
Иерархия класса влияет на требования к интерфейсам и распространению. В классическом ABAP и разных моделях разработки встречаются CX_STATIC_CHECK, CX_DYNAMIC_CHECK и CX_NO_CHECK; конкретные обязанности вызывающего кода сверяйте для целевого выпуска и языкового режима. Не выбирайте базовый класс только ради удаления строки RAISING: решение влияет на то, какие вызовы статически показывают возможный отказ.
Группируйте классы по восстанавливаемым причинам, а не по месту, где их случайно заметили. Например, неверные входные данные и временная недоступность внешней зависимости требуют разных действий. Не перехватывайте общий суперкласс, чтобы без разбора продолжать обработку: это способно превратить частичную операцию в неполный или неверный финансовый результат.
В документации SAP non-class-based exceptions описаны как предшествующая модель; для новой разработки их не следует проектировать как основной контракт. В старом коде можно встретить EXCEPTIONS, RAISE и проверку sy-subrc. При миграции нужно сохранить соответствие старых кодов ошибок и нового смысла исключений, включая поведение вызывающих систем и RFC-границ. Механическая замена sy-subrc на общий CATCH не доказывает эквивалентность.
Если расчёт сверки отклоняет дубликат ключа или разные валюты, это должно быть явным результатом контракта: специальное исключение, типизированный список ошибок или другой заранее определённый ответ. Не подменяйте ошибку нулевой суммой и не продолжайте агрегирование по оставшимся строкам без правила, утверждённого предметной моделью.
Обработка исключения сама по себе не откатывает финансовую операцию. Она не определяет границы LUW, блокировки, уже выполненные записи, внешние вызовы или компенсирующие действия. Эти эффекты проектируются и проверяются отдельно. Синтетический пример Python из соседней лаборатории не проверяет ABAP-исключения и не доказывает поведение SAP.
Ссылки ведут на документацию разных поколений ABAP и инструментов разработки. Перед применением проверьте документацию и ограничения целевой версии. Здесь нет результата синтаксической проверки, ABAP Unit или выполнения в SAP runtime.
An ABAP exception marks a situation in which normal continuation along the current execution path is not suitable. Three design questions matter: who raises it, which calling methods must declare or handle it, and at what level a correct decision can be made.
A catchable class-based exception is represented by an exception-class object. Code raises it with RAISE EXCEPTION or THROW; a handler is written with TRY ... CATCH ... ENDTRY. If a called method can propagate an exception, its contract must reflect that with RAISING, or the calling code must handle the situation.
This contract makes failures visible at call boundaries. Declaring RAISING does not mean a failure has been handled; it allows propagation to the next level. An unhandled exception can terminate a program with a runtime error. Put a handler where the information needed for a meaningful decision is available: convert the failure into a clear result, add context, or stop the operation with diagnostics.
The class hierarchy affects interface and propagation requirements. CX_STATIC_CHECK, CX_DYNAMIC_CHECK, and CX_NO_CHECK occur in classic ABAP and different development models; check the caller's obligations for the target release and language mode. Do not choose a base class just to remove a RAISING declaration: the choice affects which possible failures are visible at call sites.
Group exception classes by recoverable causes, not by where an error happened to be noticed. Invalid input and temporary dependency unavailability, for example, need different actions. Do not catch a broad superclass and continue without examining the cause; that can turn a partial operation into an incomplete or incorrect financial result.
SAP documentation describes non-class-based exceptions as the predecessor model and says they should not be defined for new development. Older code may use EXCEPTIONS, RAISE, and sy-subrc checks. A migration must preserve the mapping from old error codes to the new exception meaning, including caller and RFC-boundary behavior. Replacing sy-subrc mechanically with a generic CATCH does not prove equivalence.
If a reconciliation calculation rejects a duplicate key or mixed currencies, that must be an explicit contract result: a dedicated exception, a typed error list, or another defined response. Do not replace an error with a zero amount or continue aggregating remaining rows unless the domain rule explicitly permits it.
Exception handling by itself does not roll back a financial operation. It does not define LUW boundaries, locks, writes already performed, external calls, or compensating actions. Those effects must be designed and checked separately. The synthetic Python example in the related lab does not test ABAP exceptions or prove SAP behavior.
The links point to documentation from different ABAP generations and development tools. Check the target version and language restrictions before applying them. No syntax check, ABAP Unit run, or SAP runtime execution is reported here.