Defining Exceptions

Exceptions are represented by objects that are instances of exception classes. Defining an exception
is, therefore, the same as creating an exception class.
All exception classes must inherit from the common superclass CX_ROOT and one of its subordinate
classes:
CX_STATIC_CHECK
CX_DYNAMIC_CHECK
CX_NO_CHECK
. The assignment of exception classes to one of these three paths of the inheritance hierarchy
determines the way in which the associated exceptions are propagated. There is a record of
predefined exception classes CX_SY_... whose exceptions are raised in error situations in the runtime
environment. These classes all inherit from CX_DYNAMIC_CHECK or CX_NO_CHECK but not from
CX_STATIC_CHECK (see hierarchy in the ABAP keyword documentation).
All exception classes must begin with the prefix CX_. They are usually defined globally with the Class
Builder of the ABAP Workbench. Local exception classes can, however, also be defined.
Individual (abstract) exception classes that are used as the superclass of further exception classes
can be defined. The exceptions of the subordinate classes can be handled together using a
superclass.
Exception classes have the following features:
Constructor
The constructor must have a predefined structure and a specific interface. With global
classes, the Class Builder generates the correct constructor and sets it to an unchangeable
status. The constructor has two IMPORTING parameters:
TEXTID of the SOTR_CONC type
This parameter can be used to determine which of your exception texts the
exception will use.
PREVIOUS of the CX_ROOT type
This parameter can be used to assign the PREVIOUS attribute a previous
exception.
Methods
In exception classes, you can define your own methods. The following two predefined
methods are inherited from the root class CX_ROOT:
GET_TEXT
Sends back the exception texts of a class (controlled by the TEXTID
attribute) as a string.
GET_SOURCE_POSITION
Returns the program name, the name of a possible include program, and the
line number of the statement that raised the exception.
Attributes
The attributes of exception classes are used to transport additional information on an error
situation to the handler. The main piece of information is, however, always the fact that an
exception of a particular class has occurred. The following attributes are inherited from
CX_ROOT:
TEXTID
Used to specify the exception of a class more precisely by using
several exception texts. Is evaluated in the GET_TEXT method.
PREVIOUS
If an exception is mapped to another exception, a reference to the original
exception can be defined in this attribute via the EXPORTING addition of the
RAISE EXCEPTION statement and by means of the constructor IMPORTING
PARAMETER with the same name. This can result in a chain of exception
objects. In the event of a runtime error, the exception texts of all the
exceptions in the chain are output. Mapping an exception to another
exception is only beneficial if the context in which the original exception
occurred is important for characterizing the error situation.
KERNEL_ERRID
The name of the associated runtime error is stored in this attribute if the
exception was raised by the runtime environment, for example,
COMPUTE_INT_ZERODIVIDE with a division by zero. If the exception is not
handled, precisely this runtime error occurs.
Parameters cannot be transferred to the constructor for this attribute. If the
exception is raised with RAISE EXCEPTION, the attribute is set to initial.
Global Exception Classes
Global exception classes are defined and managed in the Class Builder. If the correct naming
convention (prefix CX_) and the class type Exception Class is chosen when a new class is created,
the Class Builder automatically becomes the Exception Builder.
The Exception Builder offers precisely the functionality required to define exception classes and
generates independently-defined components that must not be changed. When classes are created,
the category of the exception must be specified, in other words, whether it is to inherit from
CX_STATIC_CHECK, CX_DYNAMIC_CHECK, or CX_NOCHECK.
Tab Pages of the Exception Builder
The Exception Builder has the tab pages Properties, Attributes, Methods, and Texts.
The properties do not normally need to be changed.
Except for the four inherited attributes mentioned above, further public attributes can be
generated by the Exception Builder. The contents of these attributes specify the exception
more clearly and manage the exception texts.
All of the methods are inherited from CX_ROOT. New methods cannot be added. The
instance constructor is generated automatically. It ensures that, when an exception is raised,
the attributes have the right values. It also transfers the text of the superclass for an exception
class whose exception text is not specified explicitly.
The instance constructor is generated on the basis of the attributes, which are set up on the
basis of the exception texts. Changing the attributes in superclasses can, therefore, invalidate
the constructors of subordinate classes. The constructors of subordinate classes can be
regenerated under Utilities CleanUp Constructor.
Texts are a special feature of exception classes and the Exception Builder. For further
information, refer to Exception Texts.
Local Exception Classes
Local exception classes can be defined for specific exceptions that only occur within one single ABAP
program. The condition for a local exception class is that it inherits from one of the three classes
CX_STATIC_CHECK, CX_DYNAMIC_CHECK, or CX_NO_CHECK, or from their subordinate
classes. An individual constructor and individual attributes can be created. Individual methods should
not be created, however, and the methods of superclasses should not be redefined.
Examples of Local Exception Classes

report DEMO_LOCAL_EXCEPTION_1.
class CX_LOCAL_EXCEPTION definition
inheriting from CX_STATIC_CHECK.
endclass.
start-of-selection.
try.
raise exception type CX_LOCAL_EXCEPTION.
catch CX_LOCAL_EXCEPTION.
message 'Local Exception!' type 'I'.
endtry.
This example shows a minimal local exception class, which is simply the local
representation of one of the three direct subordinate classes of CX_ROOT. It
can be used in the program.

report DEMO_LOCAL_EXCEPTION_2.
class CX_LOCAL_EXCEPTION definition
inheriting from CX_STATIC_CHECK.
public section.
data LOCAL_TEXT type STRING.
methods CONSTRUCTOR importing TEXT type STRING.
endclass.
class CX_LOCAL_EXCEPTION implementation.
method CONSTRUCTOR.
SUPER->CONSTRUCTOR( ).
LOCAL_TEXT = TEXT.
endmethod.
endclass.
data OREF type ref to CX_LOCAL_EXCEPTION.
start-of-selection.
try.
raise exception type CX_LOCAL_EXCEPTION
exporting TEXT = `Local Exception`.
catch CX_LOCAL_EXCEPTION into OREF.
message OREF->LOCAL_TEXT type 'I'.
endtry.
In this example, the exception class from the previous example is extended
to include an individual attribute and constructor. The IMPORTING parameter
of the constructor must be supplied when the exception is raised (it is
required here). The attribute can be evaluated in the handler of the exception.

report DEMO_LOCAL_EXCEPTION_3.
class CX_LOCAL_EXCEPTION definition
inheriting from CX_SY_ARITHMETIC_ERROR.
public section.
methods CONSTRUCTOR importing SITUATION type STRING.
endclass.
class CX_LOCAL_EXCEPTION implementation.
method CONSTRUCTOR.
SUPER->CONSTRUCTOR( OPERATION = SITUATION ).
endmethod.
endclass.
data OREF type ref to CX_LOCAL_EXCEPTION.
data TEXT type STRING.
start-of-selection.
try.
raise exception type CX_LOCAL_EXCEPTION
exporting SITUATION = `START-OF-SELECTION`.
catch CX_LOCAL_EXCEPTION into OREF.
TEXT = OREF->GET_TEXT( ).
message TEXT type 'I'.
endtry.
In this example, an exception class is derived from one of the predefined
exception classes for error situations in the runtime environment. An
individual constructor is defined with an individual IMPORTING parameter
that supplies the superclass constructor with this parameter. When the
exception is handled, the exception text, as defined in the superclass, is read
with GET_TEXT.
http://help.sap.com/saphelp_nw04/helpdata/en/83/636d1d12fc11d5991e00508b5d5211/content.htm

Exception Reporting
Use
In exception reporting you select and highlight objects that are in some way different or critical.
Results that fall outside a set of predetermined threshold values (exceptions) are highlighted in
color. This enables you to identify immediately any results that deviate from the expected results.
Exception reporting allows you to determine the objects that are critical for a query, both online, and in
background processing.
Integration
You can define exceptions in the following area of the Business Explorer:
in the BEx Query Designer (see Defining Exceptions)
in Web Applications (see Defining and Changing Exceptions)
in the Ad-hoc Query Designer
in the Web item List of Exceptions
in the toolbar of the standard Web template
You can evaluate the exceptions online when executing the query or the Web application.
If you want to evaluate exceptions for a large number of queries, you can do this in the background.
You schedule the exceptions in the Administrator Workbench Reporting Agent for background
processing.
Features
Exception reporting is made up of three functional areas: The exception definition, the online
evaluation of exceptions, and the evaluation of exceptions in background processes.
Defining Exceptions
Exceptions are valid globally for a query in all workbooks or in all Web applications.
The definition of an exception consists of:
Determining threshold values or intervals that are given a priority (bad, critical, good). The
priority given to an exception corresponds to pre-assigned colors that become more intense
the greater the deviation. Up to 9 different shades of the traffic light colors red, yellow, and
green are used. These traffic light colors are also used in the alert monitor to display the results
of exception reporting. See also Displaying Exceptions: Alert Monitor
Determining cell restrictions. You use the cell restrictions to specify for which evaluation (cell
area) you want the exception to apply.
See also:
Defining Exceptions in the query designer or Defining and Changing Exceptions in Web applications.
Evaluating exceptions online
BEx Web applications:
The cell areas for a table are highlighted in color if they contain values that do not fall within the
exceptions you defined previously. Furthermore, you can display exceptions in maps and charts. You
can find addtional information under Display of Exceptions with Maps and Charts.
The Web item List of Exceptions enables you to list the exceptions available for a query view with
their respective status (active/inactive) listed. You can then activate or deactivate exceptions, create
new exceptions, or change existing exceptions.
BEx Analyzer
The cell areas in the results area of an executed query are highlighted in color if they contain values
that do not fall within the exceptions you defined previously.

Note that the evaluation of exceptions always comes from the original values specified
by the OLAP processor. Scaling factors and local calculations are not considered with
the evaluation of exceptions.
Evaluating exceptions in the background
Settings that you make in the Reporting Agent are processed in the background. The result is
displayed in the alert monitor, and logged in the exception log. If exceptions do occur, it is possible to
trigger a follow-up action in the Reporting Agent (a mail is sent to the person responsible, for
example).
The alert monitor is a component of the Business Explorer. It is available in:
The BEx Analyzer toolbar Open dialog box
Web applications in the alert monitor Web item.
The number of exceptions that occur is displayed according to the selection of traffic light colors. You
can specify that the system run an authorization check before displaying the exceptions. The
exceptions are displayed in a hierarchy with the following levels: InfoArea, InfoProvider, query, view,
and exception.
See also:
Reporting Agent
Defining Exceptions Settings
Displaying Exceptions: Alert Monitor
http://help.sap.com/saphelp_nw04/helpdata/en/1a/615f64816311d38b170000e8284689/content.htm

SE38 - ABAP Editor Basis - ABAP Editor
SP01 - Output Controller Basis - Print and Output Management
SE16 - Data Browser Basis - Workbench Utilities
ST22 - ABAP dump analysis Basis - Syntax, Compiler, Runtime
MB51 - Material Doc. List MM - Inventory Management
SLIS - FI-SL Spec.Purpose Ledg. Info.System FI - Information System
SQ01 - SAP Query: Maintain queries Basis - SAP Query
SPRO - Customizing - Edit Project Basis - Customizing Project Management (IMG)
SE37 - ABAP Function Modules Basis - Function Builder
MB5B - Stocks for Posting Date MM - Inventory Management
SQVI - QuickViewer Basis - SAP Query
SM37 - Overview of job selection Basis - Background Processing
RSRT - Start of the report monitor BW - OLAP Technology
SE93 - Maintain Transaction Codes Basis - Workbench Tools: Editors, Painters, Modelers
MD04 - Display Stock/Requirements Situation PP - Master Data
SUIM - User Information System Basis - User and Authorization Management
PFCG - Role Maintenance Basis - Authorization and Role Management
SE80 - Object Navigator Basis - Repository Browser
SE11 - ABAP Dictionary Maintenance Basis - Dictionary Maintenance
ME2N - Purchase Orders by PO Number MM - Purchasing


Read more: http://www.tcodesearch.com/tcodes/search?q=exception+report#ixzz2tybTEyBp