Skip to Content

Handling of errors / warnings / informational messages in class methods

Jan 17 at 08:18 PM


avatar image

Dear ABAP-OO programming experts,

we have a frequently re-occurring issue in regards to the correct way of handling errors / issues during execution of a class method. When talking about errors, I do not only refer to technical errors, but also to business errors or even warnings. Here comes our problem description:

In the old “classic” world of function modules and BAPIs, all kind of issues which came up during performing a certain action could be identified by evaluating the subrc / checking messages stored in BAPIRET structure.

When it comes to frequently re-occurring issues which are not covered by the SAP standard, we however would love to use classes and methods. For specific purposes, we thus created toolbox classes with static methods to cover basic functions without having the need of creating an object. Of course also in these methods errors and warnings can occur which need to be passed to the caller. This however always becomes a pain when using exceptions. Maybe we are not using exceptions correctly, but what we currently do is to create an exception class for each kind of error which can occur. This however is time consuming and – to be honest – a bit annoying as the number of classes grow and grow.


In method “do_something” four different kind of errors can occur. In this case we created four new exception classes. If we would have used a function module, we instead would not need to create any exception class, but instead just assign a number to the exception which then can we evaluated by the caller – way simpler. However function modules are a bit old fashioned.

My questions are the following:

How can it be avoided to each and every time create a new exception class? Of course a generic class could be used, however is this really the way how it should work?

If a certain method can throw multiple exceptions (continue processing after the first exception was raised), how do you pass multiple exceptions to the caller? Do you simply link them (make use of the previous parameter)?

How can warnings or even information messages be passed to the caller? For me, it sounds wrong to raise an exception if a warning occurred. However it might still be worth to pass this information to the calling module.

Did someone of you already faced similar issues and maybe found some kind of a template / pattern how to deal with errors / warnings / messages during execution of a class method? We already thought of something like always returning a table with error codes which then could be evaluated by the caller (similar to BAPIRET structure). These errors codes then must be specified as part of the method documentation. However this is just an idea with a lot of room for improvement.

Please note that none of us are really ABAP OO experts. So it might of course be that we missed a key aspect or did not understand the concept of exceptions at all.

Any suggestions are appreciated.

10 |10000 characters needed characters left characters exceeded
* Please Login or Register to Answer, Follow or Comment.

3 Answers

Best Answer
Matthew Billingham
Jan 18 at 08:01 AM

Use more than one textid per exception class. Then you can use one exception class for a number of errors, rather than one exception class per error. Do try not to use a generic exception class for all errors. They're still objects and should be treated as such. Exception class texts can be linked to message classes,

Exception classes are a feature of most OO languages. I suggest searching for information about exception design good practice (not ABAP restricted).

Also, as a side issue, the use of static methods "so no need to create instances" is usually a bad design choice. Especially since from 7.40 you can simply do new zcl_my_class( )->do_stuff( ). It indicates a that you're not really following an oo-paradigm.

Show 2 Share
10 |10000 characters needed characters left characters exceeded

Hello Matthew,

thanks for the advice. Personally I am not a real fan of assigning a message text in a class method as for me the calling module is responsible for the representation of the error. Maybe I am wrong here and this is exactly the way how it was designed to be done.

Secondly, my understanding is that for utility classes it is a best practice to make use of static methods (at least in Java this is the case).


I don't like linking message classes to exceptions either - I entirely agree with you on this point!

Even in Java (I develop in Java as well), static methods are frowned upon nowadays. I really don't believe that it is best practice. The main reason is that you lose the opportunity to exploit polymorphism. A couple of examples:

Let's say you've got a static utility method read_file, that reads a text file from the presentation server. Then someone comes along and says, I want to read an xlsx file. You now need to create new static utility method read_xlsx_file. In your coding using this you then have to switch on which method to use. Or you could enhance read_file, so that in some way it knows whether to read the file as text or xlsx. However, If instead you create a class of file_handler, then you just need an instance of the right type, you don't need to change any of the calling code, and you can use inheritance for shared processing within the subclasses.

Or, considering the same method. You're now building an automated test framework, and you want to simulate the reading of a file. You can create a subclass of file_handler that hands over hardcoded content,and during testing, instead of reading a file, you slot an instance of this subclass in and use that.

Now, depending on your actual methods, you might think - well, that'll never be specialised. My experience of using statics methods (as I used to for utilities) is that I've had to switch them to instance methods quite often. Often enough, that I think it's worth the effort to just make them instance in the first place. Often, as well, if you adopt the paradigm "everything is an object", then you find that the utilities do fall neatly into proper related instances. And if you do that, then you can, for example, have one exception class per superclass - which helps resolve your original issue.

Finally, if you're using some resource where there really can only be one instance, then use the singleton pattern rather than statics.

Mike Pokraka Jan 18 at 09:31 AM

+1 to Matthew's suggestion. Think of classes as message class equivalents and text IDs as message numbers, but with OO it's a lot more fine grained (more classes and less messages per class).

Creating classes need not be a pain, the whole beauty of Exception Classes is that you can add attributes and use inheritance.

So you might have ZCX_ORDER, ZCX_ORDER_PRICING. It only takes a minute to create a further subclass ZCX_ORDER_PRICING_VAT with text IDs INVALID_VAT_CODE, VAT_RATE_NOT_CONFIGURED

10 |10000 characters needed characters left characters exceeded
Horst Keller
Jan 17 at 09:59 PM
Show 2 Share
10 |10000 characters needed characters left characters exceeded

Hello Horst,

thank you very much or your quick reply and helpful feedback – indeed I was not aware of this post, mainly due to the reason that we currently are still running on ABAP 740. The upgrade is in progress, thus we should benefit from the additional features shortly.

For good orders sake, can you confirm that my understanding is correct?

1) When implementing the new interface, it is absolutely fine to use one generic exception class for all kind of errors. It is thus no longer required to search for a suitable exception class or even create a new one.

2) All kind of messages (errors, warnings, …) can be passed to the caller by using the new solution as the msgtype is also available. This does not represent a contradiction to the concept of exception handling.

Thank you very much for your guidance.


1) Technically you're perfectly right. But from a modelling perspective the use case is rather point 2 - converting existing messages - than building new applications based on just one generic exception class. For new applications, the exception class itself should carry the semantic meaning.

2) Yes