Abap error message

How To Display Error Messages In SAP ABAP?

An overview of error message types, error and pop-up messages, and how to show messages to the end user.

Published Jun 16, 2021

Message Types In ABAP

In total, ABAP has 6 types of messages.

DISPLAY LIKE Addition

As you can see from the previous table the message type can also influence the report execution after the message was confirmed. In case you want to take care of the error handling yourself or simply change the appearance of a message you can use the addition DISPLAY LIKE :

This example prints the message Message text to display in the status line with the red error icon. Since the type itself is S report execution continues normally.

Remember: The addition DISPLAY LIKE only changes the appearance, not the behavior of the message type.

Displaying Messages

Following some examples of how to output a message in ABAP.

Saving Messages In A Variable

The below examples show how to create and store a message in a variable. This can be useful when working with system variables or a message class.

See Also

I’m Dan, a software engineer and consultant passionate about SAP, web and mobile app development.

Источник

ABAP Blog

Все о разработке в решениях от SAP

ABAP Blog

Все о разработке в решениях от SAP

Ссылки

Цитаты

Мы пытаемся решить проблему, максимально ускоряя процесс проектирования, чтобы в конце работы над системой у нас осталось достаточно времени для нахождения ошибок, допущенных из-за слишком быстрого проектирования.

Гленфорд Майерс

Новое

• Получение инстанции cl_gui_alv_grid для SALV 11.09.2021
• Introduction to ABAP in the Cloud 18.08.2021
• Getting Started with FPM BOPF Integration 01.06.2021
• 30. How to Use Authority Checks in Business Object Processing Framework 29.05.2021
• 29. BOPF Extensibility 29.05.2021
• 28. BOPF Enterprise Procurement Model (EPM) 29.05.2021
• 27. BOPF Integration 29.05.2021
• 26. BOPF Business Configuration Objects 29.05.2021
• 25. BOPF Performance 29.05.2021
• 24. BOPF Supportability 29.05.2021

Последние комментарии

Обработка особых ситуаций в ABAP

Когда мы создаем какой-либо многократно используемый компонент, например функциональный модуль или метод в классе, мы сталкиваемся с необходимостью обработки непредвиденных ситуаций (какой-либо входной параметр, оказался не заполненным или доступ к файлу не был получен и т.п.), т.е. тех ситуаций, после которых программа не может выполняться далее стандартным образом, либо требуется дополнительная обработка.

В приведенной статье рассматриваются способы вызова и обработки данных ситуаций, называемых исключениями.

В ABAP есть два основных способа работы с исключениями, классический способ заключается в вызове особых ситуаций описанных в ФМ или методе на отдельной закладке:

Классический способ может использоваться и в классах:

Новый способ основывается на ООП, где в качестве исключений используются классы (обратите внимание, что установлена галочка – классы исключений):

Хочется отметить, что новый способ был введен с версии SAP Web AS 6.10 и при создании новых функциональных модулей или методов рекомендуется использовать именно его. В данной статье не рассматриваются системные исключения и их обработка до введения классов исключений.

В RFC модулях в настоящее время используется классический способ обработки исключений. Не допускается одновременно использовать классический и основанный на классах, способы обработки исключений (в интерфейсе методов, процедур, функций).

Классический способ обработки исключений

При вызове исключения, системное поле sy-subrc будет заполнено номером, под которым исключение было обозначено при вызове ФМ, метода или процедуры:

Как правило, исключения вызываются с текстом сообщения, данный текст может быть описан статически – при вызове исключения оператором MESSAGE, либо динамически – путём получения текста из описания ФМ.

Так же исключение может быть вызвано без какого-либо текста (оператором RAISE ИмяИсключения), но данный способ лучше не использовать, т.к. вызов исключения должен как-то себя расшифровывать и говорить о том, что собственно произошло.

Напишем небольшой ФМ, рассчитывающий сумму двух чисел, оба параметра помечены как необязательные, если первый параметр не будет задан при вызове ФМ, система выдаст исключение – no_num_1.

И программа для его вызова:

При запуске программы произойдет вызов исключения, т.к. был использован тип сообщения «Е», программа завершит свое выполнение после показа сообщения:

Замечу, что это вовсе не означает, что при вызове ФМ или метода и обработке исключения необходимо завершать работу программы, вы можете свободно продолжить её выполнение и далее, добавив например, сообщение об ошибке в лог программы, а не на вывод как в примере.

Ключевое слово OTHERS используется для того чтобы поймать исключения не описанные в ФМ или явно неуказанные, при вызове ФМ.

Пример вызова неописанного исключения:

В данном примере вызывается неописанное в интерфейсе ФМ исключение – no_num_2, которое будет благополучно поймано с помощью ключевого слова OTHERS (системное поле sy-subrc примет значение равное 2).

Кроме того, можно не обрабатывать большой список всех возможных исключений описанных в ФМ, тогда в случае если такое исключение будет вызвано поле sy-subrc примет значение, указанное в OTHERS.

В ФМ, могут быть добавлены новые исключения и в случае, когда при вызове ФМ они не обработаны и не указано слово OTHERS программа упадет в дамп с ошибкой времени выполнения — RAISE_EXCEPTION. Отсюда вывод, ключевое слово OTHERS подставляем всегда, при вызове ФМ (метода или процедуры), когда мы точно не уверены в неизменности компонента.

При вызове исключения в процедурах (perform…) из ФМ, система пытается найти и вызвать исключение в первом ФМ из стека вызовов, если исключение не найдено, вызывается так же, как и неопределенное исключение в ФМ.

Как уже было упомянуто выше, есть возможность получать текст непосредственно из описания особой ситуации:

ФМ будет выглядеть следующим образом:

Результат:

Иногда особые ситуации используются не как исключения, а как параметры показывающие обработку ФМ и его результат, возвращаемый в поле sy-subrc, хотя лучше бы пренебречь подобным стилем:

Сообщения, вызываемые в ФМ или методах, оператором MESSAGE, без дополнения RAISING, либо сообщения вызываемые системой (например, при обработке экранов), могут быть обработаны программой с использованием дополнения: error_message = n_error, указываемого так же после ключевого слова EXCEPTIONS.

При обработке сообщений:

• Сообщения с типом I, W, S не обрабатываются, но записываются в журнал обработки фонового выполнения, если происходит обработка в фоне.
• Сообщения с типом E или A могут быть обработаны, при этом в поле sy-subrc будет записано значение n_error. При вызове сообщения с типом А, происходит вызов ROLLBACK WORK (см. описание оператора MESSAGE).
• Сообщение с типом X не обрабатывается, программа завершается с дампом.

Обработка исключения классическим способом может быть выполнена динамически, с помощью ключевого слова EXCEPTION-TABLE. Пример:

Обработка исключений, основанная на классах

Как понятно из названия, под исключениями в данном случае понимаются объекты специальных классов исключений. Вызов такого исключения может быть выполнен либо в программе с помощью оператора RAISE EXCEPTION, либо системой (например, при делении на ноль будет вызвано предопределённое исключение CX_SY_ZERODIVIDE, список таких исключений), либо через дополнение THROW в условных выражениях (с версии ABAP 7.4).

Во всех случаях инициируется создание объекта указанного класса (если указано дополнение INTO в CATCH), в атрибутах которого содержится информация о возникшей исключительной ситуации, доступ к ним, как правило, осуществляется через методы этого класса.

Классы особых ситуаций могут быть определены как локально, так и глобально через построитель классов – транзакция SE24, диалог создания:

В данном случае галочка «с классом сообщений» означает использование в качестве текста сообщения из класса сообщений транзакция SE91 (будет рассмотрено ниже). По умолчанию текст сообщения создается в текстах класса:

Категории исключений

Все классы особых ситуаций являются производными одного из классов: CX_NO_CHECK, CX_DYNAMIC_CHECK или CX_STATIC_CHECK, которые сами являются производными общего суперкласса CX_ROOT.

• CX_STATIC_CHECK – как правило, исключения которые вызываются в процедуре (ФМ или методе), должны быть либо обработаны в ней, либо процедура должна иметь соответствующий интерфейс, чтобы вызывающий её код мог обработать эту ситуацию. Если исключение определено как потомок этого класса, оно должно быть явно указано в интерфейсе метода (ФМ или формы) в котором происходит его вызов. Данная категория используется тогда, когда в коде явно ожидается передача обработки особой ситуации на уровень выше того места где оно было вызвано. Если при статической проверке, система не увидит обработки в блоке TRY..CATCH..ENDTRY подобного исключения система выдаст предупреждение:
• CX_DYNAMIC_CHECK – при проверке кода, компилятор не будет делать предупреждений об отсутствии обработки исключений их этой категории, в случае вызова исключения его обработка будет проверена динамически и если обработчик не будет найден программа упадет в дамп. Обычно данная категория используется тогда, когда исключение может быть обработано внутри самого метода, без передачи обработки выше по стеку. Примером такой категории может являться исключение вызываемое при делении на ноль, передавать его выше по стеку и указывать в интерфейсе метода вовсе не обязательно, т.к. мы можем его обработать внутри самого метода. Однако, если мы хотим передать обработку данного исключения, необходимо указать его в интерфейсе метода.
• CX_NO_CHECK – аналогичны предыдущему типу, но данную категорию нельзя объявлять в интерфейсах, при этом классы исключений наследуемые от этого класса, неявно все же передаются в интерфейс и выше по стеку вызовов. Данную категорию следует использовать для исключительных ситуаций, которые могут произойти в любое время и не могут быть обработаны непосредственно в коде метода. Кроме того, можно использовать в случаях когда одна и та же исключительная ситуация может возникнуть во множествах методов, а объявлять её в интерфейсах каждого из методов не имеет смысла, т.к. это усложнит код. В итоге подобные исключения могут пройти всю цепочку вызовов методов (т.к. неявно передаются в интерфейс) и быть обработаны на уровне программы.

На исключения накладываются следующие ограничения:

• Исключение не может быть объявлено в интерфейсе статического конструктора:

• Исключение не может быть объявлено в интерфейсе обработчика событий. При этом если в коде обработчика произошел вызов исключения, и он не был обработан, система вызовет исключение — CX_SY_NO_HANDLER, которое может быть обработано в вызывающем его коде.
• При вызове программ через SUMBIT или CALL TRANSACTION, исключение, возникающее в вызываемой программе, не может быть передано в вызывающую программу.

Небольшой пример с локальным классом исключения:

Источник

SAP Messages

A SAP message is an essential part of any ABAP program and are used to display information to the user to let them know what’s happening. This could be in a number of ways such as an error message, warning message or information message.

The following ABAP code is the simplest way to implement a message into your report.

MESSAGE ‘Display this message’ TYPE ‘E’.

SAP Message Classes

A better way to implement your messages would be to create and maintain them via a message class using transactions SE91 or SE80. This way you have a central store for all messages, which makes it easier to maintain. This is especially true if your messages need to be translated into multiple languages. Enter your text here.

To do this you first need to create a message class which is a kind of container/wrapper where you store related messages together. Once this is done you can add as many message as you require into it. You also get the option to create additional long text, which offers the user additional information about the particular issue. See the following link for more information and details of how to create a message class.

Once you have created your message you can use them within your ABAP code using the following syntax:

MESSAGE E001(MCLASS).

MESSAGE = ABAP statement
E = Type of message (can also be I,W,S,A,X)
001 = Message number
MCLASS = Message Class

Pass message Parameters

You can also add parameters to your messages using the «&» character. So for example you could create the following message ‘Purchase order & has been deleted’. You can then pass a purchase order number to the message when using it and it will replace the «&» with the purchase order you pass for example

MESSAGE E001(MCLASS) with ekko-ebeln.

The result would display
«Purchase order 1234 has been deleted»

Further information about message types

I — Information messages
Information message are displayed in a popup window and only pause processing until you have clicked through the message.

E — Error message
An error message will be displayed in red along the footer of the SAP screen and stops processing going any further.

W — Warning message
A warning message behaves similar to and error message and is displayed along the footer of the SAP screen and stops processing going any further.

S — Success/Status message
A Success message is also displayed along the footer of the SAP screen but does not stop processing going any further and is simply displayed at the end in green.

A — Termination/Abend
A termination message stops processing and causes a runtime error and short dump which is also viewable in tcode ST22.

X — Exit
An exit message stops processing and displays and exit button which exits session processing. Similar to typing /n into the SAP command box.

Источник

Когда мы создаем какой-либо многократно используемый компонент, например функциональный модуль или метод в классе, мы сталкиваемся с необходимостью обработки непредвиденных ситуаций (какой-либо входной параметр, оказался не заполненным или доступ к файлу не был получен и т.п.), т.е. тех ситуаций, после которых программа не может выполняться далее стандартным образом, либо требуется дополнительная обработка.

В приведенной статье рассматриваются способы вызова и обработки данных ситуаций, называемых исключениями.

В ABAP есть два основных способа работы с исключениями, классический способ заключается в вызове особых ситуаций описанных в ФМ или методе на отдельной закладке:

Классический способ может использоваться и в классах:

Новый способ основывается на ООП, где в качестве исключений используются классы (обратите внимание, что установлена галочка – классы исключений):

Хочется отметить, что новый способ был введен с версии SAP Web AS 6.10 и при создании новых функциональных модулей или методов рекомендуется использовать именно его. В данной статье не рассматриваются системные исключения и их обработка до введения классов исключений.

В RFC модулях в настоящее время используется классический способ обработки исключений. Не допускается одновременно использовать классический и основанный на классах, способы обработки исключений (в интерфейсе методов, процедур, функций).

Классический способ обработки исключений

При вызове исключения, системное поле sy-subrc будет заполнено номером, под которым исключение было обозначено при вызове ФМ, метода или процедуры:

Как правило, исключения вызываются с текстом сообщения, данный текст может быть описан статически – при вызове исключения оператором MESSAGE, либо динамически – путём получения текста из описания ФМ.

Так же исключение может быть вызвано без какого-либо текста (оператором RAISE ИмяИсключения), но данный способ лучше не использовать, т.к. вызов исключения должен как-то себя расшифровывать и говорить о том, что собственно произошло.

Напишем небольшой ФМ, рассчитывающий сумму двух чисел, оба параметра помечены как необязательные, если первый параметр не будет задан при вызове ФМ, система выдаст исключение – no_num_1.

И программа для его вызова:

При запуске программы произойдет вызов исключения, т.к. был использован тип сообщения «Е», программа завершит свое выполнение после показа сообщения:

Замечу, что это вовсе не означает, что при вызове ФМ или метода и обработке исключения необходимо завершать работу программы, вы можете свободно продолжить её выполнение и далее, добавив например, сообщение об ошибке в лог программы, а не на вывод как в примере.

Ключевое слово OTHERS используется для того чтобы поймать исключения не описанные в ФМ или явно неуказанные, при вызове ФМ.

Пример вызова неописанного исключения:

В данном примере вызывается неописанное в интерфейсе ФМ исключение – no_num_2, которое будет благополучно поймано с помощью ключевого слова OTHERS (системное поле sy-subrc примет значение равное 2).

Кроме того, можно не обрабатывать большой список всех возможных исключений описанных в ФМ, тогда в случае если такое исключение будет вызвано поле sy-subrc примет значение, указанное в OTHERS.

В ФМ, могут быть добавлены новые исключения и в случае, когда при вызове ФМ они не обработаны и не указано слово OTHERS программа упадет в дамп с ошибкой времени выполнения — RAISE_EXCEPTION. Отсюда вывод, ключевое слово OTHERS подставляем всегда, при вызове ФМ (метода или процедуры), когда мы точно не уверены в неизменности компонента.

При вызове исключения в процедурах (perform…) из ФМ, система пытается найти и вызвать исключение в первом ФМ из стека вызовов, если исключение не найдено, вызывается так же, как и неопределенное исключение в ФМ.

Как уже было упомянуто выше, есть возможность получать текст непосредственно из описания особой ситуации:

ФМ будет выглядеть следующим образом:

Результат: 

Иногда особые ситуации используются не как исключения, а как параметры показывающие обработку ФМ и его результат, возвращаемый в поле sy-subrc, хотя лучше бы пренебречь подобным стилем:

Программа:

Результат:

Сообщения, вызываемые в ФМ или методах, оператором MESSAGE, без дополнения RAISING, либо сообщения вызываемые системой (например, при обработке экранов), могут быть обработаны программой с использованием дополнения: error_message = n_error, указываемого так же после ключевого слова EXCEPTIONS.

При обработке сообщений:

• Сообщения с типом I, W, S не обрабатываются, но записываются в журнал обработки фонового выполнения, если происходит обработка в фоне.
• Сообщения с типом E или A могут быть обработаны, при этом в поле sy-subrc будет записано значение n_error. При вызове сообщения с типом А, происходит вызов ROLLBACK WORK (см. описание оператора MESSAGE).
• Сообщение с типом X не обрабатывается, программа завершается с дампом.

Пример ФМ:

Программа:

Результат:

Обработка исключения классическим способом может быть выполнена динамически, с помощью ключевого слова EXCEPTION-TABLE. Пример:

Обработка исключений, основанная на классах

Как понятно из названия, под исключениями в данном случае понимаются объекты специальных классов исключений. Вызов такого исключения может быть выполнен либо в программе с помощью оператора RAISE EXCEPTION, либо системой (например, при делении на ноль будет вызвано предопределённое исключение CX_SY_ZERODIVIDE, список таких исключений), либо через дополнение THROW в условных выражениях (с версии ABAP 7.4).

Во всех случаях инициируется создание объекта указанного класса (если указано дополнение INTO в CATCH), в атрибутах которого содержится информация о возникшей исключительной ситуации, доступ к ним, как правило, осуществляется через методы этого класса.

Классы особых ситуаций могут быть определены как локально, так и глобально через построитель классов – транзакция SE24, диалог создания:

В данном случае галочка «с классом сообщений» означает использование в качестве текста сообщения из класса сообщений транзакция SE91 (будет рассмотрено ниже). По умолчанию текст сообщения создается в текстах класса:

Категории исключений

Все классы особых ситуаций являются производными одного из классов: CX_NO_CHECK, CX_DYNAMIC_CHECK или CX_STATIC_CHECK, которые сами являются производными общего суперкласса CX_ROOT.

• CX_STATIC_CHECK – как правило, исключения которые вызываются в процедуре (ФМ или методе), должны быть либо обработаны в ней, либо процедура должна иметь соответствующий интерфейс, чтобы вызывающий её код мог обработать эту ситуацию. Если исключение определено как потомок этого класса, оно должно быть явно указано в интерфейсе метода (ФМ или формы) в котором происходит его вызов. Данная категория используется тогда, когда в коде явно ожидается передача обработки особой ситуации на уровень выше того места где оно было вызвано. Если при статической проверке, система не увидит обработки в блоке TRY..CATCH..ENDTRY подобного исключения система выдаст предупреждение: 
• CX_DYNAMIC_CHECK – при проверке кода, компилятор не будет делать предупреждений об отсутствии обработки исключений их этой категории, в случае вызова исключения его обработка будет проверена динамически и если обработчик не будет найден программа упадет в дамп. Обычно данная категория используется тогда, когда исключение может быть обработано внутри самого метода, без передачи обработки выше по стеку. Примером такой категории может являться исключение вызываемое при делении на ноль, передавать его выше по стеку и указывать в интерфейсе метода вовсе не обязательно, т.к. мы можем его обработать внутри самого метода. Однако, если мы хотим передать обработку данного исключения, необходимо указать его в интерфейсе метода.
• CX_NO_CHECK – аналогичны предыдущему типу, но данную категорию нельзя объявлять в интерфейсах, при этом классы исключений наследуемые от этого класса, неявно все же передаются в интерфейс и выше по стеку вызовов. Данную категорию следует использовать для исключительных ситуаций, которые могут произойти в любое время и не могут быть обработаны непосредственно в коде метода. Кроме того, можно использовать в случаях когда одна и та же исключительная ситуация может возникнуть во множествах методов, а объявлять её в интерфейсах каждого из методов не имеет смысла, т.к. это усложнит код. В итоге подобные исключения могут пройти всю цепочку вызовов методов (т.к. неявно передаются в интерфейс) и быть обработаны на уровне программы.

На исключения накладываются следующие ограничения:

• Исключение не может быть объявлено в интерфейсе статического конструктора:

• Исключение не может быть объявлено в интерфейсе обработчика событий. При этом если в коде обработчика произошел вызов исключения, и он не был обработан, система вызовет исключение — CX_SY_NO_HANDLER, которое может быть обработано в вызывающем его коде.
• При вызове программ через SUMBIT или CALL TRANSACTION, исключение, возникающее в вызываемой программе, не может быть передано в вызывающую программу.

Небольшой пример с локальным классом исключения:

В стандартной системе SAP имена всех классов особых ситуаций начинаются с CX_ , пользовательские исключения рекомендуется называть, начиная с ZCX или lcx для локальных классов исключений.

Класс CX_ROOT предоставляет некоторые предопределенные методы, которые наследуются всеми классами особых ситуаций:

• Метод GET_SOURCE_POSITION возвращает имя главной программы и (если связаны) имена включенных программ (инклудов) и номер строки исходного кода, в которой возникла особая ситуация.
• Метод GET_TEXT возвращает текст особой ситуации в форме строки.
• Метод GET_LONGTEXT возвращает подробный текст текста особой ситуации в форме строки.

Тексты исключений

Каждому классу можно присвоить несколько текстов. Присвоенные им идентификаторы создаются построителем классов как константы в атрибутах класса. Тексты сохраняются в репозитарии текстов (OTR). Константы идентификаторы, представленные в шестнадцатеричном формате, уникальны на уровне системы:

Доступ к хранилищу текстов можно получить через транзакцию SOTR_EDIT.

В текстах можно определить параметры, их необходимо обозначить в амперсандах. В качестве примера, можно рассмотреть текст из класса исключения — CX_SY_FILE_IO:

В параметры будут переданы (при вызове метода GET_TEXT) соответствующие им атрибуты класса:

Заполняются эти атрибуты в конструкторе при вызове исключения:

Так же в конструкторе можно указать, какой текст должен использоваться при инициировании особой ситуации, передав одну из определенных констант в параметр импорта TEXTID. Не рекомендуется использовать подобную методику, т.к. это может запутать код, однако как было уже показано выше SAP сам это использует (read_error, write_error в CX_SY_FILE_IO). Инкапсуляция текстов в классах сообщений и их саморасшифровываемость является одним из преимуществ над классическими исключениями.

Конструктор, который генерируется автоматически в SE24, для нового созданного исключения (ZCX_NO_NUM1), выглядит так:

Блок обработки исключений

Особая ситуация может быть обработана, только если оператор, который может инициировать ее, заключен в блок TRY-ENDTRY. Затем особая ситуация обрабатывается с помощью оператора CATCH в блоке TRY-ENDTRY.

Блок TRY содержит набор операторов, обрабатывающих особые ситуации. Если в блоке TRY появляется особая ситуация, система осуществляет поиск первого оператора CATCH в том же блоке TRY-ENDTRY, а затем последовательно снаружи во всех заключающих блоках TRY-ENDTRY, обрабатывающих особую ситуацию. Если оператор находится, система осуществляет переход к его обработчику. Если обработчик найти не удается, но блок TRY-ENDTRY находится в процедуре, система осуществляет попытку передачи особой ситуации вызывающей программе.

Блок CATCH содержит обработчик особых ситуаций, исполняемый при возникновении указанной особой ситуации в связанном блоке TRY. Для оператора CATCH можно указать любое количество классов особых ситуаций. Таким образом, определяется обработчик особых ситуаций для всех этих классов особых ситуаций и их подклассов.

Блоки TRY-ENDTRY могут иметь вложенность любой глубины. Поэтому блок TRY, блоки CATCH и блок CLEANUP в целом сами могут содержать полные блоки TRY-ENDTRY.

При возникновении особой ситуации система осуществляет поиск по перечисленным обработчикам особых ситуаций в указанном порядке. Затем она исполняет первый обработчик особых ситуаций, оператор CATCH которого содержит подходящий класс особой ситуации или один из ее суперклассов.

Если ошибка не будет обработана и не будет передана вызывающей программе, система выдаст дамп с ошибкой времени выполнения — UNCAUGHT_EXCEPTION, в том случае когда не обрабатывается исключительная ситуация, связанная с ошибкой времени выполнения, система выдает дамп с ошибкой времени выполнения (например, CX_SY_CONVERSION_CODEPAGE — CONVT_CODEPAGE):

Просмотр ошибки в транзакции ST22:

Распространение особых ситуаций

Если возникает особая ситуация (наследуемая от CX_DYNAMIC_CHECK, CX_STATIC_CHECK), она автоматически распространяется на все уровни стека вызовов, до тех пор, пока она не будет обработана или пока не встретится такой интерфейс, в котором она (либо её предки) будет отсутствовать.

Следующий пример демонстрирует распространение особой ситуации на несколько методов:

Обратите внимание на метод do_calc, в нем описана особая ситуация от которой наследуется lcx_summ_error, соответственно прерывание продолжится на следующий уровень и будет обработано в блоке TRY..CATCH..ENDTRY. При правильно выстроенной архитектуре наследования исключительных ситуаций, прозрачность кода заметно повышается.

В случае, когда используется исключение, наследуемое от CX_NO_CHECK, описание его в интерфейсе метода может быть опущено, т.к. оно инициируется неявным способом системой:

Очистка после вызовов исключений

Блок CLEANUP исполняется, когда выполнен выход из блока TRY-ENDTRY, так как система не смогла найти обработчик для исключения в определенном блоке TRY-ENDTRY, но особая ситуация обрабатывается в окружающем блоке TRY-ENDTRY или передается вызывающей программе.

Данный блок обычно применяется для освобождения занятых ресурсов: очистке ссылочных переменных, закрытие локаторов или наборов данных (datasets) и т.п. Допустим, Вы записываете некоторые данные в файл на сервере приложений. Внутри блока TRY Вы открываете набор данных (dataset) и начинаете запись в него. Однако в некоторый момент, случается особая ситуация, которую вы не обработали и блок TRY прерывает свою работу, при этом, не выполнив закрытие набора данных. Для того чтобы избежать подобной ситуации воспользуемся ключевым словом CLEANUP:

В случае возобновляемых оператором RESUME исключений, блок CLEANUP не выполняется. Блок CLEANUP, как и блок CATCH позволяет получить ссылочную переменную на вызванное исключение, с помощью дополнения [INTO oref].

Передача исключений по цепочке

Необходимо понимать, что особая ситуация может передаваться через любое количество иерархий вызова перед финальной обработкой. Одна особая ситуация может инициировать вторую и т. д. Каждая инстанция должна оставаться действительной, независимо то того, был ли связанный блок CATCH уже обработан или нет. Поэтому необходимо убедиться, что предыдущая инстанция особой ситуации доступна с помощью, по крайней мере, одной ссылки. Атрибут общей инстанции PREVIOUS, наследуемый всеми классами особых состояний из CX_ROOT, обеспечивает удобный для этого способ.

Пример:

Таким образом, пройдя по цепочке, мы всегда можем определить, в каком конкретном месте было инициировано исключение и что из-за этого произошло. Иногда при построении какой-либо ООП модели, удобно собрать всю цепочку из ошибок в каком-нибудь одном виде и выдать в качестве универсального исключения, в качестве примера рекомендую посмотреть этот пример.

Возобновляемые исключения и повтор блока TRY

При срабатывании исключения, выполнение программы в текущем контексте завершается. Иногда необходимо не завершать выполнение текущего контекста, для этого были созданы так называемые возобновляемые исключения. Для того чтобы вызвать такое исключение, необходимо в операторе RAISE (или в THROW) указать что вызывается именно возобновляемое исключение, при этом для того чтобы воспользоваться оператором RESUME (который возвращает код обратно в то место где было вызвано исключение), необходимо у оператора CATCH указать дополнение BEFORE UNWIND (обозначает обработку возобновляемого исключения), иначе система вызовет исключение CX_SY_ILLEGAL_HANDLER. При возврате в контекст, из которого было вызвано исключение блок CLEANUP не вызывается. Если в указанном в CATCH блоке не будет вызван оператор RESUME, контекст будет удален при выходе из блока CATCH.

Пример обработки возобновляемого исключения:

При обработке исключений так же есть возможность повтора блока TRY..CATCH, делается это с использованием оператора RETRY. Пример:

В данном случае если номер 2 будет равен нулю, система вызовет исключение, с помощью RETRY мы заново запустим блок TRY..CACTH, при этом уже исключение не возникнет, т.к. при делении нуля на ноль результатом будет ноль.

Отображение сообщений из классов сообщений в тексты исключений

Начиная с версии 6.40, появилась возможность связывать тексты исключительных сообщений с классами сообщений (транзакция SE91). Как уже упоминалось выше для этого необходимо в конструкторе класса, указать галочку класс сообщений. При этом вместо интерфейса IF_MESSAGE будет внедрен интерфейс IF_T100_MESSAGE (таблица T100 хранит в себе эти сообщения):

При редактировании текста, необходимо будет привязать его к классу и номеру сообщения, при этом заполнить параметры, если это необходимо:

Начиная с NW 2004, оператор MESSAGE позволяет напрямую обработку исключений, внедряющих интерфейс IF_T100_MESSAGE:

Локальный класс исключения в приватном методе глобального класса

Бывают ситуации, когда для какого-либо приватного метода необходимо реализовать исключение, которое может быть вызвано исключительно данным методом (классом).  Реализовать подобное можно, если создать локальный класс исключений:

• Перейти в локальные определения/внедрения:

• Создать класс исключения:

•  Указать в методе имя локального класса исключения (обязательно в режиме редактирования исходного кода):

Результат:

Если попробовать сделать тоже самое в режиме редактирования на основе формуляров, выскочит предупреждение о том, что такого класса не существует:

Более подробно об исключениях можно почитать в официальной документации:

http://help.sap.com/abapdocu_740/en/abenabap_exceptions.htm

Оператор MESSAGE служит для диалогового взаимодействия с пользователем. Существует шесть типов сообщения.

Тип	Описание
S	Status (Success). Сообщение отображается в статусной строке и не влияет на работу программы. Данный вид сообщения применяется для информирования об успешной выполнении операции.
W	Warning. Предупредительные сообщения отображаются в статусной строке. При возникновении сообщения работа программы прерывается, а пользователю предоставляется возможность вносить исправления в полях для ввода. При нажатии на Enter в диалоговом режиме, работа программы будет восстановлена.
E	Error. Сообщение отображается в статусной строке. При возникновении данного вида сообщения обработка программы останавливается.
I	Information. Информационное сообщение отображается в отдельном модальном окне. При возникновении сообщения работа программы прерывается. После закрытия диалога работа программы восстанавливается.
A	Abend (Abort). Сообщение отображается в модальном окне. При возникновении сообщения программа завершается, а система возвращается в меню более высокого уровня. Сообщения стоит применять только в крайних ситуациях.
X	Exception. Сообщение инициирует дамп MESSAGE_TYPE_X. Данный вид сообщения стоит применять в ситуациях, когда нужно проанализировать что именно привело к ошибке во время выполнения.

Синтаксис

MESSAGE { msg | text | exception }
{ { [DISPLAY LIKE dtype] [WITH dobj1 … dobj4] }
| { [DISPLAY LIKE dtype] [WITH dobj1 … dobj4] RAISING exception }
| { [WITH dobj1 … dobj4] INTO text } }.

После вызова оператора MESSAGE заполняются системные поля

Для вывода сообщений используются классы сообщений, которые создаются в тр. SE91

MESSAGE — msg

При выводе сообщений нужно указать: класс, номер и тип сообщения

MESSAGE tn(id)
MESSAGE tn
MESSAGE ID mid TYPE mtype NUMBER num.

Результат работы программы

MESSAGE — text

MESSAGE text TYPE mtype.

В также MESSAGE можно передать свободный текст. В этом случае класс сообщения будет 00, номер сообщения 001. Данный вариант обычно используют когда нет возможности определить сообщения в SAP, например когда текст сообщения формируется во внешних системах.

Результат работы программы

В системных полях будет сообщение базисного класса 001(00)

MESSAGE — exception

MESSAGE oref TYPE mtype.

В также MESSAGE можно передать исключение. Результат будет аналогичен выводу исключения.

Результат работы программы

Значения системных полей

MESSAGE — WITH

MESSAGE … WITH dobj1 … dobj4.

Сообщения могут содержать параметры, которые передаются через дополнение WITH. Пример вывода сообщения 076(va) с двумя параметрами.

Результат работы программы

MESSAGE — DISPLAY LIKE

MESSAGE … DISPLAY LIKE dtype.

При использовании дополнения DISPLAY LIKE, происходит замена иконки на специфичную для типа, указанного в dtype. В dtype можно передать одно из следующих значений: A, E, I, S или W. Данное дополнение нельзя использовать для сообщения типа X, оно всегда вызывает дамп. DISPLAY LIKE обычно используется в ситуациях, когда нужно отобразить ошибку, но не прерывать выполнение программы.

Результат работы программы

MESSAGE — INTO

MESSAGE … INTO text.

При использовании дополнения INTO, в переменную text записывается короткий текст сообщения. Само сообщение при этом, не отображается. Данное дополнение обычно применяют в двух случаях: когда нужно получить текст сообщения; когда нужно заполнить системные переменные для дальнейшего использования, например, для журнала приложений.

MESSAGE — RAISING

MESSAGE … RAISING exception.

Оператор MESSAGE вместе с дополнением RAISING представляет собой комбинацию операторов MESSAGE и RAISE. Данное дополнение имеет смысл только во время обработки методов и функциональных модулей, в которых определено исключение старого типа (основанного не на классах). Если вызывающий метод или функциональный модуль обрабатывает данное исключение в EXCEPTIONS, то MESSAGE .. RAISING работает аналогично оператору RAISE. Если же вызывающей стороне исключение не обрабатывается, то RAISING игнорируется.

Preface – This post is part of the ABAP Beginner series.

Introduction

A programmer always tries to code in such a way that his code is bug free and full proof. But there are certain scenarios, where his codes can fail. In such case, if the coder already knows the scenarios, then he handle them in form of Error handling. But, in case of situations, where an error can be generated due to unknown situations and left un-handled can cause serious dumps. For these scenarios, we have exception handling in SAP. In this article we will explore all scenarios of Exception and Error Handling in ABAP Reports

Exception and Error Handling in SAP ABAP Reports

As discussed above, a coder is required to handle known issues as well as intended error messages. These messages are shown to user in the output via MESSAGE statement.

Different ways to catch Errors/Exception

ABAP provides various ways to catch errors in an ABAP program.

1. Using System Variable

The simplest way is to use their system variables.

 SY-SUBRC EQ  0. "This statement indicates that an operation completed successfully.
 SY-SUBRC NE  0. "This statement indicates that an operation has failed.

This way works directly if the entire code of report was process within the same program. It means, it cannot catch an error directly in case you have processed a Function Module or ABAP Class statements. For those entity, we need to raise exception from their end, and then exception can be handled in the report and processed accordingly.

1. Catching Errors based on Exception

In case, we implement a function module or method of a class, then it is important to raise exception from these classes and then we can catch these exceptions in report and show respective error.

For Example:

CALL FUNCTION 'Test_Function'
     EXPORTING
          DELIMITER =   ':'
          STRING        =   lv_string
     IMPORTING
          HEAD           =   lv_head
          TAIL             =   lv_tail
     EXCEPTIONS
          NOT_FOUND   =  1
          OTHERS       =   2.


CASE SY-SUBRC.
     WHEN 1. ...
// Show Error Message
     WHEN 2. ...
// Show Error Message
     WHEN OTHER.
// Show Error Message
ENDCASE.

1. Using TRY CATCH ENDTRY

In case an exception is raised via a method of class, or an unexpected exception is raised, in these cases, we use TRY CATCH functionality of SAP ABAP. This is one of the best full proof way to handle all types of exceptions.

Example:

TRY.
     //Call your class or function module here
CATCH CX_SY_ZERODIVIDE INTO O_REF. // The exception you have raised there
     MESSAGE “Your Error Message”.
ENDTRY.

Different ways to show Messages

1. Using ABAP Statement

Syntax:

MESSAGE ‘<Enter Your Text here>’ TYPE ‘Enter the type of Message here’.

Types of Message

ABAP provides the following 6 types of messages:

1. Using Predefined Function Modules

ABAP provides following function modules that can be used to store, format and show messages altogether:

Example:

1. Using Message Statement

MESSAGE 'This is an error message' TYPE 'E'.

1. Using Multiple functions to store and show messages:

" It is Initialized only initially...
* Initialize your messages
  CALL FUNCTION 'MESSAGES_INITIALIZE'
    EXCEPTIONS
      log_not_active       = 1
      wrong_identification = 2
      OTHERS               = 3.
"One by one append all your messages here
      PERFORM store_messages USING 'E'
                                   w_pn
                                   w_batch2
                                   w_werks
                                   ' '
                                   w_msgno.
FORM store_messages USING p_msgty
                          p_msgv1
                          p_msgv2
                          p_msgv3
                          p_msgv4
                          p_txtnr.
  IF p_msgty EQ 'E'.
    w_err_fg = 'X'.
  ENDIF.
* Store all your messages meant to be displayed
  CALL FUNCTION 'MESSAGE_STORE'
    EXPORTING
      arbgb                  = 'ZCCH001'
      msgty                  = p_msgty
      msgv1                  = p_msgv1
      msgv2                  = p_msgv2
      msgv3                  = p_msgv3
      msgv4                  = p_msgv4
      txtnr                  = p_txtnr
    EXCEPTIONS
      message_type_not_valid = 1
      not_active             = 2
      OTHERS                 = 3.
ENDFORM.                    " STORE_MESSAGES
"In the end fetch all your message and show them altogether
* This displays all the messages in a popup
  CALL FUNCTION 'MESSAGES_SHOW'
    EXPORTING
      show_linno         = ' '
    IMPORTING
      e_exit_command     = wa_exit_command
    EXCEPTIONS
      inconsistent_range = 1
      no_messages        = 2
      OTHERS             = 3.

1. Using HR_DISPLAY_ERROR_LIST

DATA:
it_error        TYPE STANDARD TABLE OF HRERROR,"TABLES PARAM
wa_error     LIKE LINE OF it_error .
DATA(ld_no_popup) = 'some text here'.
DATA(ld_no_print) = 'some text here'.
DATA(ld_no_img) = 'some text here'.
DATA(ld_no_msgno) = 'some text here'.
DATA(ld_linesize) = '123 '.
DATA(ld_listheader) = 'Check type of data required'.
DATA(ld_colheader) = 'Check type of data required'.
DATA(ld_hidemsg) = 'some text here'.
 
 
"populate fields of struture and append to itab
append wa_error to it_error.
.
CALL FUNCTION 'HR_DISPLAY_ERROR_LIST'
* EXPORTING
*   no_popup =                   ld_no_popup
*   no_print =                   ld_no_print
*   no_img =                     ld_no_img
*   no_msgno =                   ld_no_msgno
*   linesize =                   ld_linesize
*   listheader =                 ld_listheader
*   colheader =                  ld_colheader
*   hidemsg =                    ld_hidemsg
* TABLES
*   error =                      it_error
  EXCEPTIONS
    INVALID_LINESIZE =           1
    .  "  HR_DISPLAY_ERROR_LIST
IF SY-SUBRC EQ 0.
  "All OK
ELSEIF SY-SUBRC EQ 1. "Exception
  "Add code for exception here
ENDIF.

Popular posts from this blog

What is Message?

Messages are used to describe what is happening in the program execution to the programmer or user. Messages represents with a three-digit number. Messages range starts from 000 to 999.

Message Types —

Messages are basically six types. Those are —

Message Usage —

Messages can be added to the program mostly in two ways. Those are —

• Coding directly in the program
• By using the message class.

Coding directly in the program —

Coding the message directly in the program is a very simple process. No definition was required before coding the message in the program.

Syntax —

MESSAGE {message-name} TYPE {message-type}.

• Message — 80 characters user defined message.
• Message-type — Specifies the message type.

Now, let us see how different message types coded one by one with seperate examples.

*&---------------------------------------------------------------------*
*& Report  Z_MESSAGE
*&---------------------------------------------------------------------*
*& Written by TutorialsCampus
*&---------------------------------------------------------------------*

REPORT  Z_MESSAGE.

* Displaying Abend Message of type A
MESSAGE 'This is a Abend message' TYPE 'A'.

*&---------------------------------------------------------------------*
*& Report  Z_MESSAGE
*&---------------------------------------------------------------------*
*& Written by TutorialsCampus
*&---------------------------------------------------------------------*

REPORT  Z_MESSAGE.

* Displaying error Message of type E
MESSAGE 'This is a Error message' TYPE 'E'.

*&---------------------------------------------------------------------*
*& Report  Z_MESSAGE
*&---------------------------------------------------------------------*
*& Written by TutorialsCampus
*&---------------------------------------------------------------------*

REPORT  Z_MESSAGE.

* Displaying Informational Message of type I
MESSAGE 'This is a Informational message' TYPE 'I'.

*&---------------------------------------------------------------------*
*& Report  Z_MESSAGE
*&---------------------------------------------------------------------*
*& Written by TutorialsCampus
*&---------------------------------------------------------------------*

REPORT  Z_MESSAGE.

* Displaying Success Message of type S
MESSAGE 'This is a Success message' TYPE 'S'.

*&---------------------------------------------------------------------*
*& Report  Z_MESSAGE
*&---------------------------------------------------------------------*
*& Written by TutorialsCampus
*&---------------------------------------------------------------------*

REPORT  Z_MESSAGE.

* Displaying Warning Message of type W
MESSAGE 'This is a Warning message' TYPE 'W'.

*&---------------------------------------------------------------------*
*& Report  Z_MESSAGE
*&---------------------------------------------------------------------*
*& Written by TutorialsCampus
*&---------------------------------------------------------------------*

REPORT  Z_MESSAGE.

* Displaying Exit Message of type X
MESSAGE 'This is a Exit message' TYPE 'X'.

Using the message class —

In this scenario, messages gets displayed from the message class that is defined by using MESSAGE-ID along with the REPORT command. Message number is a three-character code that can define a set of 1000 messages and those are accessed when MESSAGE command executed in the program.

Messages number ranges from 000 to 999 (i.e. 1000 messages). Each message associated with message number and the message length can be upto 80 characters.
When a message number used in the program, the corresponding message retrived from the message class and gets displayed.

Syntax —

MESSAGE {message-name} WITH field1 ... field4.

This addition replaces the placeholders «&1» to «&4» and «&» of the short text or «&V1&» to «&V4&» of the long text of of the operands field1, …, field4. Up to four operands field1 through field4 can be specified.

Messages are not always static and some part of the message can be filled with a dynamic or runtime text.
While creating a custom message, Amber sign (&) symbol used in the place of dynamic or runtime text.
The MESSAGE…WITH statement used to pass the dynamic or runtime text during the program execution.