Runtime Errors, exceptions in Smart Forms

Each Smart Form can trigger a number of exceptions during its execution. To limit this number of exceptions, you can bundle the occurring errors in error classes and store them in an error log in the composer. This documentation covers the details of Runtime Errors, exceptions in Smart Forms

 For each error, you store an internal error number and (if possible) a message from table T100 (work area, message number, message text and parameters) in addition to the error class. To each error class, you assign an exception, which means that if the recognized error terminates the form processing, the system triggers exactly this exception. When an exception occurs, the caller of the Smart Form can use predefined function modules to read the error log and then decide which reaction is appropriate in the respective error context.

Possible exceptions for the generated function module are:

In addition, you can define your own exceptions.

If an error (or a warning) occurs, the system internally fills an error table. The application can now read this table as soon as the function module for the form is processed to the end. To read the table that contains all errors and warnings that occurred, call function module SSF_READ_ERRORS. The table has structure SSFERROR. The fields in the table are the number of the document within the
job, the form name, an error number, a message class, a message type, a message number and four additional message variables. If processing is terminated, the application can dynamically display a message. The error numbers are defined in the include SSF_ERROR.

If you want to trigger your own exception in the free coding of the Smart Form, you can use one of the following methods:

More References