- SAP Managed Tags:
Preface
In this series, we look at the various factors that need to be considered when using class-based exceptions. The series is not an introduction to class-based exceptions. It assumes that the reader is familiar with the basics and has used class-based exceptions before. The intention of this series is to provide our own insights which would hopefully help the programming community make more informed choices with regards to exception handling. However, it should be pointed out that the content of this blog has also been influenced by various other blogs/articles written by other developers on this topic. Some of those have been listed below: -
- thomas.weiss/blog/2005/03/22/the-new-class-based-exception-handling-in-abap--part-1
The following are the various topics that we’ll look at in this blog series: -
- Why do we raise exceptions?
- General principles when handling/raising exceptions
An Insight into Exception Handling - 2 - Different types of exceptions – How do we choose?
- Inheritance in exception classes – How do we use this to our advantage?
In this blog, we’ll look at first topic – Why do we raise exceptions?
Example Scenario
The principles of exception handling have been explained using the following ‘Library’ example: -
The library is a part of a university and has books which are available on loan to its members.
All students of the university are, however, not its members. Students need to be registered as members in the library before they can loan books.
The library is responsible for registering students as members. The library is also responsible for de-registration of students. However, de-registration must only be possible if books loaned by the student have been returned. The library is responsible for lending books that members want to borrow. It is also responsible for receiving books that members want to return. A book which has already been loaned-out cannot be loaned by another member unless it has been returned back to the library by the member. Additionally, the library does add new books to its stock or may remove existing books from its stock (if they have damaged). Each book is uniquely identified by its title (This is not realistic but we want to keep the example simple) and can have only copy.
The student must get himself registered as a member of the library if he wants to loan books from the library. Each student is uniquely identified by his name. The student can loan books and also return books back to the library. The student can get himself de-registered (provided he doesn’t have any un-returned books) from the library.
The following class diagram depicts the various classes: -
Why do we throw exceptions?
All program units (method/FM) generate outputs. By, outputs we are not only referring to the exporting and changing parameters of the program units, but also referring to any target (file, internal table, database table…etc.,) that the processed data could be written into.
The output has a domain i.e.., a list of possible values which indicate the result of execution of the program unit. If during the execution of the method/FM, a state is reached which cannot be adequately described by any value in the output domain, and as a result of which further execution cannot continue, we know that we have encountered an exceptional state. And, throwing an exception would be a good idea at this point.
This can be illustrated by an example program depicted by the following sequence diagram. Please note that some details have been omitted out for the sake of brevity: -
- In this example, the main program first creates an instance of the library (lo_library) and the student lo_student1 (Divyaman).
- We then create three books – lo_book1 (Catcher in the Rye), lo_book2 (The Kite Runner) and lo_book3 (A Thousand Splendid Suns).
- The books lo_book1 (Catcher in the Rye) and lo_book2 (The Kite Runner) are then added to the library stock.
- The book lo_book1 (Catcher in the Rye) is then loaned-out by the student lo_Student1 (Divyaman).
- The main program then determines which of the three books have been loaned out. It calls the IS_BOOK_LOANED method to determine that. The following result is printed on the screen: -
Catcher in the Rye has already been loaned-out
The Kite Runner is available to be loaned out
A Thousand Splendid Suns is available to be loaned out
The result is correct for ‘Catcher in the Rye’ and ‘The Kite Runner’ but not for ‘A Thousand Splendid Suns’. This book is not even available in the library’s stock and therefore cannot be loaned-out.
The reason for this incorrect message for ‘A Thousand Splendid Suns’ is explained below.
The source-code of the IS_BOOK_LOANED method is as follows: -
DATA: lv_current_title TYPE string,
lv_is_available TYPE boole_d.
CALL METHOD find_loan_by_book
EXPORTING
im_book = im_book
IMPORTING
ex_book_loan = lwa_book_loan.
IF lwa_book_loan-student IS NOT INITIAL.
ex_is_loaned = abap_true.
ELSE.
ex_is_loaned = abap_false.
ENDIF.
The IS_BOOK_LOANED method (source-code) assumes that the book for which loan-assignments are being checked exists in the library stock. In the case of ‘A Thousand Splendid Suns’, that is not the case. However, The EX_IS_LOANED parameter is returned as blank misleading the caller to believe that the book can be loaned-out since it hasn’t already been loaned.
The output (EX_IS_LOANED) can only be ‘X’ (The book has been loaned) or space (The book has not been loaned). The situation encountered here (The book is not in library stock) cannot be described accurately using any of the values available in the output domain. Therefore, it is essential that we introduce an exception that indicates the unavailability of the book. - The IS_BOOK_LOANED method can be changed as follow: -
If the book does not exist in stock, we’ll raise an exception. Otherwise, we continue with the rest of the code.
The caller can then catch this exception and display a message to indicate that the book is not available in the library.
The source code of IS_BOOK_LOANED is as follows after the changes: -
Definition: -
METHODS is_book_loaned
IMPORTING
im_book TYPE REF TO zcl_book
EXPORTING
ex_is_loaned TYPE boolean
RAISING
zcx_book_loans_exc.
Implementation: -
DATA: lv_current_title TYPE string,
lv_is_available TYPE boole_d.
DATA: lwa_book_loan TYPE wa_book_loan.
CALL METHOD is_book_available
EXPORTING
im_book = im_book
IMPORTING
ex_is_available = lv_is_available.
IF lv_is_available = abap_false.
RAISE EXCEPTION TYPE zcx_book_loans_exc.
ENDIF.
CALL METHOD find_loan_by_book
EXPORTING
im_book = im_book
IMPORTING
ex_book_loan = lwa_book_loan.
IF lwa_book_loan-student IS NOT INITIAL.
ex_is_loaned = abap_true.
ELSE.
ex_is_loaned = abap_false.
ENDIF.
Calling Program: -
TRY.
CALL METHOD lo_library->is_book_loaned
EXPORTING
im_book = lo_book3
IMPORTING
ex_is_loaned = lv_is_loaned.
IF lv_is_loaned = abap_true.
WRITE: /, lo_book3->get_title( ), ' has already been loaned-out'.
ELSE.
WRITE: /, lo_book3->get_title( ), ' is available to be loaned-out'.
ENDIF.
CATCH zcx_student_reg_dereg_excs.
WRITE: /, lo_book3->get_title(), 'is not available in the Library.
ENDTRY.
Exception handling has also been introduced at the points where the IS_BOOK_LOANED method was called for books lo_book1 (Catcher in the Rye)
and lo_book2 (The Kite Runner). Those code-snippets have not been included here for the sake of brevity.
The result of program execution after code changes is as follows: -
Catcher in the Rye has already been loaned-out
The Kite Runner is available to be loaned out
A Thousand Splendid Suns is not available in the library
| User | Count |
|---|---|
| 5 | |
| 4 | |
| 4 | |
| 4 | |
| 3 | |
| 3 | |
| 2 | |
| 2 | |
| 2 | |
| 2 |
