Skip to Content
Technical Articles

Local ABAP exception classes (inside global classes)


Why use local exception classes?

Although it is generally best practice to create global exception classes, they can seem a bit overkill for some applications. Think of PoCs, demo scenarios, BAdI implementations, etc. A handy but not so well-known option for these situations is to define a local exception class inside the global class. These allow internal exceptions (exceptions raised within the class itself) to be handled without the need for another global DDIC object. The SAP Help Portal describes local classes as follows:

Local definitions, especially local classes, can be useful as auxiliary classes for the global class. In local classes you can encapsulate implementation details that should not be visible from the outside (they should not even occur in the private section).

Class editor: source-code based or ADT ⚠️

Before you get coding, take into consideration that local exception classes do not play well with the classical Form-Based Class Builder. Use the Source Code-Based editor or Eclipse with ADT instead.

An overview of the editor choices available


Defining a local exception class


Source-code based Class Builder

To add a local exception class definition within a global class first open the global class in SE24 or SE80. Next, open the menu path Goto → Local Definitions/Implementations → Local Definitions/Implementations.

Opening the 'local definitions/implementations' section in the Class Builder


Alternatively, you can click the toolbar button labeled ‘Local Definitions/Implementations’. You can now enter the logic for the local exception class.

The button labeled 'Local definitions/Implementations' in the Class Builder


Eclipse with ADT

To add or edit a local class definition in the ABAP Development Tools in Eclipse, first open the global class. Do this via double-clicking the corresponding entry in the Project Explorer or via the ‘Open ABAP Development Object’ tool. Open the latter via its menu option Navigate → Open ABAP Development Object or its corresponding keyboard shortcut Ctrl + Shift + A.

The menu path 'Open ABAP Development Object' in the ABAP Development Tools in Eclipse


After opening the global class, define the local exception class in the tab ‘Class-relevant Local Types’. Next, open its local types section by clicking the tab labeled ‘Local Types’. You can now enter the definition and logic.

As noted by Matthew Billingham in the comment section, usually, it’s fine to just have the local class definition in the ‘Local Types’ tab. However, this can cause problems in some cases. Prevent potential issues by declaring the class separately using ‘DEFINITION DEFERRED’ in the ‘Class-relevant Local Types’ tab.

The tab named 'Local Types' in the ABAP Development Tools in Eclipse



The example below showcases a basic exception class for handling exceptions in an ALV reporting class.

*"* use this source file for the definition and implementation of
*"* local helper classes, interface definitions and type
*"* declarations
CLASS lcx_ca_gen_report DEFINITION INHERITING FROM cx_dynamic_check.
    INTERFACES if_t100_dyn_msg.
    ALIASES msgty FOR if_t100_dyn_msg~msgty.


Example local class definition in the Class Builder


We can now use this exception class in the internal methods of the global class.

"Program error in ALV-based output list, contact support
RAISE EXCEPTION TYPE lcx_ca_gen_report
    MESSAGE e014(j_3rvatd).


Further reading


Local exception classes can provide distinct exceptions to internal class methods without creating a new global exception class. However, do they have added value in a particular situation? What is your opinion? Do you consider them a useful option for specific cases or a bad habit for lazy developers? Good practice or bad practice?
Share your feedback in the comments 👇

You must be Logged on to comment or reply to a post.
  • One point, is that you should declare the local exception class in the Class-relevant Local Types tab, and the definition in the Local Types tab.

    Usually, it's fine to have the definition in the Local Types tab, but it can cause problems sometimes that would need to to put a DEFINITION DEFERRED in the Class-relevant Local Types tab anyway.

    Good idea for prototyping though. Thanks.

  • I often find myself wondering when to (best) use those seperate class includes and in which scenarios - but thanks to your Blog I have a better Idea now!

    Great and to the point Blog with all necessary information! Thanks for sharing!




  • Hi Laurens Deprost,.

    This is a nice blog at the right time for me. When I was ready with reading, I immediately intended to write. I like the idea of local exception classes because I use them in some rare cases as a possibility for coding control. As such, it is surely a better behaviour to define them as local objects. Just yesterday, I created a global exception class for exactly such a purpose. So I thought, 'Cool, that helps me avoid creating an object that nobody else needs!'.

    You kindly provided the blog with some links. So I read these too, and now I am in trouble! In the CleanCode chapter for "Error handling" is written:

    "Exceptions should be reserved for cases that you don't expect and that reflect error situations. Misusing exceptions misguides the reader into thinking something went wrong, when really everything is just fine." 

    I wrote a method that recursively calls itself until it finds either a result (which is returned) or it fits a specific status (and no result is needed). Currently, I no idea how to solve this problem without using an exception excepting I export to values and check both.

    To discuss this (using exceptions as a controlling instrument or not), I assume it needs another blog, isn't it?

    To use local exception classes as intended in the mentioned Clean Code chapter seems a little strange to me.

    I believe I'm a little confused now, or not? Could please someone help out?

    Cheers, Jens

    • Hi Jens,

      My 2 cents...

      We had a scenario similar to yours. In our case both initial & non-initial "result" are valid. If "initial" result, then different callers would react in different ways. 

      Our approach was to enhance the "result" as a structure with 2 fields:

      • Value: Both zero/non-zero values
      • Status: An enumeration detailing why the "value" is zero

      The caller of the method can now use the status to control the program flow.

    • Hi Jens Schmitt-Bousska,

      The use of exceptions as controlling instruments is indeed a discussion in itself.

      The consensus to only use exceptions for error situations and not for flows that occur in 'normal' processing makes sense. That said, it seems justifiable to me specifically for recursive methods that are sufficiently encapsulated. Alternative methods to stop the chain after finding a result will be probably be significantly more verbose/less clear.

      For your specific use case you can try to keep track of the result and/or status in a member variable and check/update its value in the recursively called method.
  • Local exception classes are great. However personally I rarely put them into class-relevant local types. You only need that if you need the local class to be part of the class definition (i.e. METHODS ... RAISING lcx_...). If this is the case, then there's possibly a good argument for making it a global exception.

    If the exception is only used in code, not in the definition (e.g. dynamic or inherited exceptions), then local definitions are fine.

    Inheriting global exceptions is very useful to make things more meaningful.

    For example gateway methods have /iwbep/cx_mgw_busi_exception in their interface for business exceptions. You don't need to create an implementation of an inherited class, just:

    CLASS lcx_order_not_found DEFINITION INHERITING FROM /iwbep/cx_mgw_busi_exception.

    and you have a more meaningful exception. One can raise any subclass exception in code if a superclass is defined in the method signature.

    • Thanks for your insights Mike Pokraka.
      I agree that most use cases are better off with either 'regular' local exception classes or global exception classes. Using class-relevant local types lends itself to very specific contexts (BAdIs, a demo scenario for which you don't want too many objects, etc.).

      Fantastic tip on inheriting /iwbep/cx_mgw_busi_exception without having to create an implementation in gateway projects. Doing this never occured to me before while it's a quick and easy way to provide more meaningful exceptions indeed.