Wood J. Object-Oriented Programming with ABAP Objects

Подождите немного. Документ загружается.

8 | Error Handling with Exceptions

"Exception handler block

CATCH cx_...

"Exception handler block

CLEANUP.

"Cleanup block

ENDTRY.

Listing 8.2 Basic Form of the TRY...ENDTRY Control Structure

The TRY statement separates the normal application flow from the exception-

handling flow(s) by creating separate execution blocks. The TRY block contains

the normal application code that may trigger various types of exceptions. These

exceptions are handled by special exception handler blocks called

CATCH

blocks

that contain code that is used to recover from a particular exception situation in

some application-specific kind of way. You also have the option of adding a spe-

cial

CLEANUP

block to do any sort of cleanup work that might need to be done

before the

TRY

statement returns control to the normal program flow. This basic

flow of a

TRY

statement is depicted in the diagram shown in Figure 8.1.

Figure 8.1 Activity Diagram for TRY...ENDTRY Control Statement

204

Dealing with Exceptions

Sometimes, developers see the class-based part of all this and assume that these

features can only be used in ABAP Objects classes. However, class-based excep-

tions were designed to be used in all ABAP contexts and should be taken advan-

tage of in procedural subroutines, event blocks, and so on.

8.3 Dealing with Exceptions

Two different types of exceptions can occur during the course of an ABAP pro-

gram: those that are raised programmatically using the

RAISE EXCEPTION

state-

ment, and those that are raised automatically by the ABAP runtime environment.

Exceptions that are raised by the ABAP runtime environment cannot always be

handled within the context of a running program. In this case, a runtime error

(i.e., a short dump) occurs, and the program abends (has an abnormal end). In fact,

all unhandled exceptions result in a runtime error because the problem condition

was never formally addressed in the program. In this section, we will look at how

to use the

CATCH

and

CLEANUP

statements to recover from exception situations that

can be handled programmatically.

8.3.1 Handling Exceptions

As you have seen, exceptions are dealt with inside of

a CATCH

block,

CATCH

blocks

are designed to handle exceptions of

particular type (or,

you will see, a family

of related types). The exception type is defined in terms of

exception class that

is part of an inheritance hierarchy based on the common

CX_R00T

superclass.

Many predefined exception classes are available out of the box in any AS ABAP

installation. It is also possible to define your own custom exception types (see

Section 8.5, Creating Exception Classes, for more details).

Whenever an exception of

particular type is raised, the system will search for a

corresponding CATCH block to handle that exception. To demonstrate how this

works, let's consider some example code that handles a class cast exception.

The

TRY

block in Listing 8.3 contains some code that performs an illegal widening

cast between the object reference variables l r_parent and l r_chi Id. At runtime,

the ABAP runtime environment will detect the invalid cast and raise an exception

of type

CX_SY_M0VE_CAST_ERROR,

which is handled in the corresponding

CATCH

block. The ABAP keyword documentation describes the types of exceptions that

205

8 | Error Handling with Exceptions

may occur whenever an ABAP statement is executed. To figure out which excep-

tion class to use. a search was performed on the keyword

MOVE,

which showed

that an exception of type

CX_SY_MOVE_CAST_ERROR

can occur in an assignment

statement using object reference variables. The relevant logic needed to recover

from the error can be implemented inside the

CATCH

block. The code in Listing 8.3

generates a simple error report on the screen (see Figure 8.2).

CLASS 1d_parent DEFINITION.

PUBLIC SECTION.

METHODS: a. b.

ENDCLASS.

CLASS lcl_parent IMPLEMENTATION.

METHOD a.

ENDMETHOD.

METHOD b.

ENDMETHOD.

ENDCLASS.

CLASS lc1_chiId DEFINITION

INHERITING FROM lcl.parent.

PUBLIC SECTION.

METHODS: c.

ENDCLASS.

CLASS lcl.chlld IMPLEMENTATION.

METHOO c.

ENDMETHOD.

ENDCLASS.

lr_parent TYPE

REF TO Icl.parent.

1r_chiId

TYPE REF TO lcl_chiId.

lr_ex TYPE

REF TO cx_sy_move_cast_error.

1v_progname

TYPE

syrepid.

1v_inclname

TYPE syrepid.

v_li

TYPE i.

lv_text TYPE

string.

1v_longtext

TYPE

string.

206

Dealing with Exceptions

8.3

* Attempt a widening cast where the dynamic type of the

* source object reference is not compatible with

* the static type of the target object reference:

TRY.

CREATE OBJECT 1r.parent.

CREATE OBJECT 1r_chiId.

HOVE 1r.parent ?TO lr_child.

CATCH cx_sy_move_cast_error INTO lr_ex.

* Read information about the exception:

CALL METHOD 1r_ex->get_source_position

IMPORTING

program_name - lv_progname

include.name - lv_inclname

source_line - lv_line.

lv_text - lr_ex->get_text( ).

lv_longtext - 1r_ex->get_longtext( ).

CONDENSE 1v_longtext.

* Output an error report about the exception:

WRITE: / 'Error Report'.

ULINE.

WRITE: / 'Program Name:'. lv_progname.

WRITE: / 'Include Name:'. lv_inclname.

WRITE: / 'Line Number:', lvjine.

WRITE: / 'Short Text:'. lv_text.

WRITE: / 'Long Text:', lvjongtext.

ENOTRY.

Listing 8.3 Handling a Class Cast Exception Using the TRY Statement

16E fa ooe^uofl A^AA BE ©a

Program YEXCEPTIONTEST

Prop* itXCtPTIOKIEST

Error Resort

frogr* <u*e ttlCCfll«ITI$T

Inclu* y(IC('IIOnTE*t

line \u»:*r 4)

thort T«.t Source type \MOtMlt>ttIttr!IONICSItCUSt«l.aj«MNf h not coep»tible. tor tne purpose* «f *Ml»<«r>t. eitn urgtt tjpe

l<ng fext

C-u-ir.; » -C*ST- operetton (•»•• Oder iKf»t » !©•)» type conflict occurred rr* «oxce t>pe \fMMM«i1XtlfTI0H1($T\CUSMa

fMIin

Figure 8.2 Generating an Exception Report Using Exception Objects

207

8 | Error Handling with Exceptions

The details of the error report generated in the

CATCH

block in Listing 8.3 were

obtained via method calls made using the

r_ex object reference variable. The

lr_ex object reference variable is initialized using the optional

INTO

addition of

the

CATCH

statement

. Here, notice that the static type of the ir_ex object refer-

ence is compatible with the exception type

CX_SY_MOVE_CAST_ERROR.

As you can

see, an exception object can be used to obtain quite a bit of useful information

about the exception, including a short and long text description of the problem,

the line number in the program that triggered the exception, and so on.

You can include as many

CATCH

blocks as you want inside of

a TRY

statement. For

example, there might be certain types of exceptions that are raised from methods

class

lcl_parent or lcl_chtld. Whenever an exception is raised in a

TRY

state-

ment with multiple

CATCH

blocks, the system searches through the

CATCH

blocks to

find a suitable handler that can handle an exception of a given type. Sometimes,

it may be preferable to use a generic exception type in an exception handler block

to handle families of related exceptions. For example, rather than setting up a

specific exception handler block to handle exception types such as division by

zero and arithmetic overflow (which are defined in exception classes

CX_SY_ZERODIVIOE

and

CX_SY_ARITHMETIC_0VERF10W,

respectively), you could

define a

CATCH

block using the

CX_SY_ARITHMETIC_ERR0R

superclass. However, if

you use generic exception types in your

CATCH

blocks, they must be declared after

any

CATCH

blocks that define exception handlers for subordinate classes. If you

think about it, this makes sense as the more specific exception handlers would

never be reached because the system would first find a matching exception han-

dler for the superordinate class. If all of this seems confusing, don't worry, the

compiler will cell you where you've gone wrong.

A tendency of some developers new to the class-based exception handling con-

cept is to create extremely large

TRY

statements that surround their entire pro-

gram logic. This is a very poor design practice that minimizes the effectiveness of

the exception handlers. A good rule of thumb is to create

TRY

statements that

encapsulate a single logical unit of work. Therefore, ifyou find that you are mix-

ing and matching many different types of exception classes in

CATCH

blocks, it is

likely that your

TRY

statement is too large. Smaller

TRY

statements are much easier

to follow and trace.

1 If

the

INTO

addition of

the

CATCH

statement is not used, an exception object will not be generated

to conserve system resources.

208

Dealing with Exceptions

Similarly, it is also important to avoid cutting corners when defining CATCH blocks

by making the exception handlers too generic. For example, as you will see in

Section 8.5, Creating Exception Classes, the root of the exception type hierarchy

is class CX_R00T. You could create an all-encompassing CATCH block using this

exception type that would handle all of the possible exceptions that could be han-

dled in an ABAP program (see Listing 8.4). The problem with this approach is that

it makes it very difficult to implement custom exception handling logic for spe-

cific types of errors. Therefore, it is worth the additional effort to go ahead and

configure specific exception handlers to avoid the headaches associated with

refactoring the exception handling logic down the road.

TRY.

Statements...

CATCH cx_root INTO lr_ex.

ENDTRY.

Listing 8.4 Example of a Lazy Design Using Generic Exception Types

8.3.2 Cleaning up the Mess

After we have recovered from an exception situation in a

CATCH

block, it is likely

that we may need to perform some additional cleanup tasks before we hand con-

trol back over to the normal program flow. For example, let's imagine that you

are writing some code to output some data to a file. Inside the

TRY

block, you

open up a file and start writing records to it. However, at some point, an excep-

tion occurs, and processing halts in the

TRY

block before you get a chance to close

the file. In this case, you can use the optional CLEANUP block to close the file

because this block is guaranteed to be called by the ABAP runtime environment

before the

TRY

statement is exited. A simplified example of this scenario is shown

in Listing 8.5.

TRY.

* Open the extract file for output:

OPEN OATASET lv.file FOR OUTPUT IN TEXT MODE

ENCODING OEFAULT.

* Transfer the extract records to the file:

LOOP AT lt.extract INTO ls_record.

PERFORM sub_format_record CHANGING ls_record.

209

8 | Error Handling with Exceptions

TRANSFER 1s_record TO lv_f11e.

ENOLOOP.

* Close the output file:

CLOSE OATASET lv_file.

CATCH cx_sy_file_access_error INTO 1r_file_ex.

* Process I/O errors...

CATCH lcx_format_error INTO 1r_format_ex.

* Process custom formatting errors...

CLEANUP.

* Clean up any used external resources:

CLOSE OATASET lv_file.

ENDTRY.

FORM sub_format_record CHANGING ps_record TYPE ...

RAISING lcx_format_error.

RAISE EXCEPTION TYPE 1cx_format_error...

ENOFORM.

Listing 8.5 Releasing External Resources Using the CLEANUP Block

Note that the

CLEANUP

block in a

TRY

statement is guaranteed to be called when-

ever an exception occurs regardless of whether or not the system can actually

locate a suitable exception handler in that

TRY

statement. As you will see in Sec-

tion 8.4, Raising and Forwarding Exceptions, if an exception handler is not

found, the exception will be propagated up the call stack as the system continues

to search for a valid exception handler. Prior to exiting, the

CLEANUP

block is exe-

cuted to clean up any local resources used within the context of the current

TRY

statement.

You should only use the

CLEANUP

block for its intended purpose because it does

not support statements that are used to alter the control flow of

program such

RETURN, STOP,

and so on.

8.4 Raising and Forwarding Exceptions

Exceptions can be raised by statements in various parts of any program. Some-

times, it is best to deal with these exceptions close to the point where they are

triggered; other times, it makes sense to forward these exceptions on to another

part of the program that is better suited to deal with the problem. In the follow-

210

Raising and Forwarding Exceptions

ing sections, we will look closely at how exceptions are triggered and consider

options for forwarding these exceptions up the call stack.

8.4.1 System-Driven Exceptions

As you saw in the example from Listing 8.3, it is possible for regular ABAP state-

ments to trigger an exception at runtime. These exceptions are triggered automat-

ically by the ABAP runtime environment. The types of exceptions that can be trig-

gered are predefined in the system, and their names begin with the CX_SY_ prefix.

To find out the possible exceptions that might be triggered for a particular ABAP

statement, consult the ABAP keyword documentation.

Most of

the

time, exceptions raised by the runtime environment are an indication

of some kind of error in your program logic. For example, an exception of type

CX_SY_ZERODIVIDE probably reveals a place in your code where you failed to

check the value of a divisor before performing a division operation. Conse-

quently, runtime exceptions such as these are said to be unchecked exceptions.

Here, it may or may not make sense to implement a CATCH block to handle these

errors because they should never occur in a valid program. You will learn more

about checked and unchecked exception types in Section 8.5.1, Understanding

Exception Class Types.

8.4 2 The RAISE EXCEPTION Statement

Most of the time, you shouldn't have to worry too much about system-driven

exceptions after your code has been thoroughly tested. However, this doesn't

mean that exception situations will not occur in your programs. For example,

imagine that you are tasked with writing a utility method to look up a customer's

credit rating. The input to this method is the customer's ID number; the output is

the customer's credit score. A simple scaffolding of this method is provided in

Listing 8.6.

CLASS lc1_customer DEFINITION.

PUBLIC SECTION.

METHODS:

get_credit_rating IMPORTING im_customer_id

TYPE bu_partner

RETURNING VALUE(re_rating)

TYPE i.

211

8 | Error Handling with Exceptions

ENOCLASS.

CLASS 1cl_customer IMPLEMENTATION.

METHOO get_credi t_rati ng.

* Read the customer master record from the database:

SELECT SINGLE *

INTO ...

FROM butOOO

WHERE partner EO im_customer_id.

IF sy-subrc NE 0.

re.ratlng - -1.

RETURN.

ENDIF.

ENDMETHOD.

ENDCLASS.

Listing 8.6 Handling Errors in the Application Logic - Part 1

The first step in this method is to look up the customer master record using the

customer number provided in the importing parameter im_customer_id. How-

ever. look at what happens whenever the provided customer number is invalid.

Because it is not possible for the method logic to continue without a valid cus-

tomer number, a dummy credit rating (i.e., -1) is returned to the caller. Here, it is

assumed that the caller of the method will check the value of the credit rating to

determine if it was valid.

The exception-handling technique shown in Listing 8.6 is not veiy intuitive. For

example, let's assume that the customer's credit score is calculated based on the

popular F1CO* credit score used within the United States. Based on this assump-

tion. users of method get_credit_rating should expect to receive valid credit

scores in the range of 300 to 850. Passing back undefined values such as -1 can be

dangerous because unwitting developers may accidentally use this value incor-

rectly. From a design perspective, it is better to throw up a red flag so thatyou can

bring this exception situation to the attention of the caller. This can be achieved

using the RAISE EXCEPTION statement.

The RAISE EXCEPTION statement is used to explicitly trigger an exception of

par-

ticular type. The basic syntax for the RAISE EXCEPTION statement is given in Listing

8.7.

212

8 | Error Handling with Exceptions

PUBLIC SECTION.

METHODS:

get_credit_rating IMPORTING im_customer_id

TYPE bu_partner

RETURNING VALUE(re_rat1ng)

TYPE i.

ENDCLASS.

CLASS lcl.customer IMPLEMENTATION.

METHOD get_credit_rating.

* Read the customer master record from the database:

SELECT SINGLE *

INTO ...

FROM butOOO

WHERE partner EO im_customer_id.

IF sy-subrc NE 0.

RAISE EXCEPTION TYPE 1cx_customer_not_found.

ENDIF.

ENDMETHOD.

ENDCLASS.

Listing 8.9 Handling Errors in the Application Logic — Part 2

Ifyou try to compile the code in Listing 8.9, you will receive a warning during the

syntax check that indicates that the exception type lcx_customer_not_found is

not caught or declared in the RAISING clause of the get_cred1t_rating method.

You have two options for dealing with exceptions that are triggered using the

RAISE EXCEPTION statement:

• You can deal with it directly via a

TRY

statement.

• Ifyou are in a procedure (i.e., a method, a function module, or a subroutine),

you can forward the exception on to the caller of that procedure

You have already seen how to handle exceptions in a TRY statement, and you will

learn how to forward exceptions in Section 8.4.3, Propagating Exceptions.

2 The exceptions to this rule are class constructors and event handler methods. It is not reasonable

to forward exceptions from these methods because they arc called implicitly by the ABAP runtime

environment.

214