You’ve been asked to create a new feature. You’re ready to build it. But hold your horses. Before you start, I suggest you find answers to a few questions. Finding a good answer to each of them is fundamental to ensuring that what you build is solid and elegant.
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. Now imagine the following scenario. You are in the BANANA1 module doing something. There, you must call a class from the MORANGO module. Of course, this class launches exceptions of the type ZCX_MORANGO. This is the context.
In classes, consider using exceptions classes over the old ones. These have great advantages and, once understood, are simple and allow for simpler code.
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.