For many years, when confronted with ABAP OO, most ABAPers I talked to, acknowledged that OO is great for most languages but never saw any real advantage in adopting it for ABAP. So they carry on using FORMs, INCLUDEs and CALL FUNCTIONs. The standard SAP code sets the example by trying to make something work while breaking every possible programming best practice.

This article was written by José Vília:

The Dolly sheep was alive in ABAP and I didn’t know about it.

Having created a class instance, I’d like to share it with another totally independent program to use it as if the instance had been created there.

It’s an ABAP Dolly sheep factory we’re talking about here, people. Serialization in the ABAP world.

If you’re not already using ABAP Objects you’re chicken.

If you use them, I do hope you’re following the best practice of using class exceptions.

And if you’re using class exceptions you better understand the best way of using them, particularly the advantages of chaining them.

This said, here’s what brings us here today. In the post about chained exceptions I showed a way to get the text of the deepest exception in the chain by using a WHILE loop:

Some time ago I wrote an article explaining a way to automatically convert classic exceptions to exception classes. Today I use this technique in almost all the exception classes that I create (and I’ve even improved it, but I’ll leave that for another post).

This tip explains the exact opposite.

We are constantly learning. But once in a while we learn something which is a leap forward forcing us to look in a new way to everything we do. The last time this had happened was when I started using OO in ABAP. OO was not new to me as I had already used it extensively in Java, C#, C++, etc. But to finally be able to apply these precious concepts on my daily job was a relief and a big improvement in the quality, flexibility and speed of my work.

If you’re still not using exception classes, then you’re making a mistake. Cause they are very healthy for your code. They’re not only good nutrients for the system, they also make it lean and less vulnerable to diseases.

There are cases where you still need to deal with the old exceptions. For example, when a function module is invoked.

In this article I am presenting a suggestion that seems a little complex, but it works very well if you need to integrate the old exceptions with exception class in a simple way. And though it is sophisticated, you only need to do it once. Once it’s done, it’s easy to use.

Today I will teach you how to chain exceptions. It’s a very practical solution to a complicated, not so obvious problem. Let’s start by describing the problem. Imagine you are in the application BANANA. The application is quite complex. It has three modules: BANANA1, BANANA2 and BANANA3. Each one has its exception class ZCX_BANANA1, ZCX_BANANA2 and ZCX_BANANA3. Since the application is in fact well designed, all the exception classes inherit from the same ZCX_BANANA.

In classes, consider using exceptions classes over the old ones. These have great advantages and, once understood, are simple and allow for simpler code. https://zevolving.com/2011/12/class-based-exception/

SAP R/3 repository is a wonderful thing. A vast warehouse of data elements, structures, tables and much more, readily available to one and all. As developers, it is extremely convenient to quickly pick these elements and pull them into our programs as necessity conveys, while our string of thought remains virtually uninterrupted. Well, not all is sunshine and roses. If you are not careful with the mushrooms you pick you might get a poisoned one.

All code to be put in user-exits (BADIs, enhancements, SMOD, etc.) should be encapsulated. It’s common for an user-exit to include multiple independent parts. Each of these parts should be encapsulated in its own method. Even if it is only one line; This should apply to both new implementations and changes to existing code; A change to existing code should always be seen as an opportunity to organize existing code into methods, since it will have to be tested again anyway;

Official ABAP Programming Guidelines (page 34): [When a classical processing block is required], you should immediately delegate the execution to a suitable method (see Rule 6.37, No Implementations in Function Modules and Subroutines, and Rule 6.44, No Implementations in Dialog Modules and Event Blocks).

All new developments should be implemented using ABAP Objects unless still impossible (RFC, IN UPDATE TASK, screens, etc). Existing developments, when rewritten, should also be converted to OO, if it proves to be realistic. Official ABAP Programming Guidelines (page 32) rule 3.1: Use ABAP Objects whenever possible for new and further developments. Classical processing blocks may be newly created in exceptional cases only. pdf/why-abap-objects.pdf https://scn.sap.com/people/thomas.jung/blog/2007/12/19/update-your-abap-development-skills-to-sap-netweaver-70 https://wiki.

Exception classes let you state multiple texts describing the different possible errors that they can represent.

However, there exists an option to associate it with a message class (SE91). This allows texts to be defined as classic SE91 messages instead of being defined directly in the exception class. And it has advantages.

Imagine you have a herd of related classes sharing between them a whole bunch of constants. Saying the same thing a different way, would you like all the classes of the herd to have easy access to the bunch of constants?

(If you’re confused, then let me tell you that the “herd” thing was just to baffle you)

Carrying on…..

SAP has a book called Official ABAP Programming Guidelines which describes rules and best practices on how to program in ABAP. In there you can read: Page 42: Rule 3.1: Use ABAP Objects whenever possible for new and further developments. Classic processing blocks may be newly created in exceptional cases only. Page 45: Within such a [classic] processing block, however, you should immediately delegate the execution to a suitable method (see Rule 6.