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. :wink:
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.
Bluesky