Skip to Content

I’ve always had a love-hate relationship with assertions. My first encounter with them was in Java, where they are used extensively in unit testing frameworks such as JUnit. In this context, I see the utility of them for testing invariants and the like. However, for run-time checks, I’ve always preferred the use of class-based exceptions which are generally more informative, graceful, and flexible. Having reached my wits end with an SAP standard API which shall remain nameless, I thought I would document a few assertion usage anti-patterns for production-ready ABAP development. Naturally, much of this is very subjective, so make of it what you will. Enjoy. ๐Ÿ˜‰

Anti-Pattern #1: ASSERT 1 = 2

Did your brain just short-circuit? Mine sure did the first time I encountered this idiom. You’d be amazed at how many times I stumble across assertions like this in SAP-delivered and custom-delivered ABAP code. To me, this practice goes against everything assertions stand for. This is not so much a predicate statement used to validate an invariant, but rather a case of developer simply yanking on the emergency brake whenever the code has dropped into a state that they didn’t know how to handle. In my mind, if you’re going to deal with this sort of thing using assertions, the assertion should be used up front to ensure that the code never reaches such a state to begin with. Otherwise, a run-time exception makes better sense in my estimation since it gives users the option of catching the exception and failing gracefully as opposed to simply short dumping.

Anti-Pattern #2: Using Assertions as a Substitute for all Defensive Programming Techniques

I think some developers get carried away with assertions, assuming that they are an across-the-board replacement for defensive programming techniques. This practice leads to brittle APIs which aren’t very flexible. Here, it is important to remember that there are some data issues which are in fact recoverable. To simply dismiss these cases as assertion errors is, to me, lazy. In my mind, assertions are one of many tools in the defensive programming tool bag (insert “If all you have is a hammer…” quote here), and should only be used in cases where they make sense.

Anti-Pattern #3: Using Assertions as a Substitute for all Class-Based Exceptions

Though the line between when to use assertions instead of class-based exceptions can be blurry at times, I think a general rule of thumb here would be to use class-based exceptions in any situation where there is a chance of recovery. Here, keep in mind that the term “recovery” doesn’t always imply that we end up achieving our end goals. Instead, it might mean that we output some meaningful information to a log before terminating the program, raising an alert, etc. With an assertion-based short dump, all we have to go on is what was captured in Transaction ST22.

Anti-Pattern #4: Defining Assertions in Production Code without Assigning a Checkpoint Group

Many purists may argue with me on this, but I think that any production code should at least give users the option of turning assertions off. For example, if the API is being used as part of a batch program which loads many records at a time, it might be desirable to simply log an exception for record 2,357 of 10,000 without killing the batch job via a short dump. Naturally, it goes without saying that such decisions should not be made lightly. After all, if assertions are used correctly, there are few legitimate cases where we would ever want to ignore them. In those handfuls of cases though, it is quite handy to have the option of flipping a switch in a checkpoint group.

To report this post you need to login first.

9 Comments

You must be Logged on to comment or reply to a post.

  1. Tom Van Doorslaer

    Hey James,

    That’s a nice article right there.

    I advise you to take contact with one of the moderators to move it into the ABAP space. that way, it will get more attention and you’ll get more recognition for it.

    I personally think the assertion statement is one of the least understood statements in ABAP. At least I still don’t get it, but your article is getting me there ๐Ÿ™‚

    Cheers!

    (0) 
    1. Otto Gold

      Hello James,

      Tom si right, this one is quite useful, let’s have it moved to the ABAP space. It will get you and the topic more readers (plus comments, I believe, which are often the best way how to get feedback and get the discussion going).

      Cheers,

      Otto

      (0) 
      1. Tom Van Doorslaer

        It would be useful in such cases to have a “notify moderator” button for positive highlighting instead of just having a “report abuse” for only negative purposes. (off-topic)

        (0) 
  2. Former Member

    There are legitime cases for #1.

    There it goes.

    create object lo_Type_A .

    lo_Type_A->do_something( ) .

    try .

        lo_Type_A->check_consistency( ) .

      catch consistency_error .

        raise exception type invalid_input_data .

    endtry .

    create object lo_Type_B .

    lo_Type_B->do_something( ) .

    try .

        lo_Type_B->check_consistency( ) .

      catch consistency_error .

        raise exception type invalid_input_data .

    endtry .

    try.

        lo_Type_A->save( ) .

        lo_Type_B->save( ) .

      catch consistency_error .

          assert 1 = 2 .

    endtry .

    Last try-catch block is used only for one purpose: supress warning message in syntax check, since inconsistency of objects can not occur.

    (0) 
    1. Matthew Billingham

      I do not agree this is legitimate. The correct way in my view is to add the #pragma that suppresses the message, and comment why you’re suppressing the message.

      Also, the design looks incorrect to me:

      create object lo_Type_A .

      lo_Type_A->do_something( ) .

      try .

          lo_Type_A->check_consistency( ) .

           lo_Type_A->save( ).

        catch consistency_error .

          raise exception type invalid_input_data .

      endtry .

      create object lo_Type_B .

      lo_Type_B->do_something( ) .

      try .

          lo_Type_B->check_consistency( ) .

          lo_Type_B->save( ).

        catch consistency_error .

          raise exception type invalid_input_data .

      endtry .

      would be better, I think.

      (0) 
      1. Former Member

        Using of #pragma is an option. But. Each such use of supression of particular warning message then must be properly documented. Otherwise reader will not recognise proper logic from laziness of developer.

        Original programm will create both objects or none. For this paricular programm this is consistency constrain.

        (0) 
        1. Matthew Billingham

          If you’re using something like ASSIGN 1 EQ 2, then that also has to be properly documented, as at first glance it’s insane. So using a pragma is better, since it’s exactly what it is for.

          If the program is to save both or none, then it should be

          create object lo_Type_A .

          lo_Type_A->do_something( ).

          create object lo_Type_B .

          lo_Type_B->do_something( ).


          try .

              lo_Type_A->check_consistency( ) .

              lo_Type_B->check_consistency( ) .

               lo_Type_A->save( ).

              lo_Type_B->save( ).

            catch consistency_error .

              raise exception type invalid_input_data .

          endtry .


          (0) 
    2. Former Member Post author

      Hi Ratis,

      I guess I can never see a situation where purposefully triggering a short dump is a good idea. This is all very subjective, but I think that in your scenario I would probably want to log the exception condition somewhere (e.g. the UI, job log, or BAL) and then try to terminate gracefully while perhaps sending a notification behind the scenes to get development involved in troubleshooting the problem. To me, this is a more elegant approach than pulling the ASSERT emergency break and freaking out the end users (and Basis). But that’s why we have forums like this for people to change my mind. ๐Ÿ˜‰

      Thanks,

      James

      (0) 
      1. Matthew Billingham

        There are occasions where you do want a short dump. I think the above example isn’t really one of them – but it is just an example ๐Ÿ™‚ . If the system has managed to get itself into an inconsistent state, a short dump gives whoever is doing the analysis considerable information. If you want a short dump, I’d suggest a message of type X would be more appropriate. It gives more information than ASSERT 1 = 2, which only means “something has gone wrong”. 

        Nowadays, I don’t use message type X either. For all applications, I have a log in which I record any inconsistencies, and report a meaningful error back the user, giving information to pass on to the technical team.  “Tell your administrator there’s a problem with xyz”.

        (0) 

Leave a Reply