When I talk with people about ABAP quality, the way they think of dumps always amazes me.
Most people believe dumps are their worst enemy. Actually they are not. Actually you're lucky if your software dumps.
How is that?
In order to understand this, we need to talk about why software dumps in the first place. Software dumps because it runs into a corrupt state it can no longer process, something virtually breaks and further processing is impossible. This results in a dump. Operation ends. Users swears.
While this is not good, it provides one important benefit: you now know you have a problem.
Ask yourself the following question: "What if my business application runs into a corrupt state and doesn't dump (right away) ?"
In this case your program may continue to operate for an unknown time span, potentially corrupting your persistent business data. If this happens, you won't find out for some time. If you find out, you may have a very hard time to recover from this data corruption and to trace it back to the actual programming defect that caused it.
Finding a problem that shows no (visible) symptoms can be extremely difficult. And its effects can be devastating once you discover them.
How would you - for example - cure a disease that shows no (visible) symptoms? You couldn't. Because you don't know it's there. Until it may be too late. But if you see the symptoms, you can treat that disease and even take action to improve your health in general.
Under that aspect, you're lucky if your program dumps. It's like a problem that waves at you with a white flag: "Hey, here I am. Fix me!".
Now if you're a Padawan, you'll find the bug and you'll fix it.
If you're a Jedi, you'll think about a process to avoid robustness issues in the future.
And if you're a Jedi Master, you'll learn from every future mistake and adapt/improve your processes as new bugs come along.
I encourage you to see dumps as a chance, not an enemy. A chance to improve the development process. A chance to avoid similar mistakes in the future. And a reminder that robust programming matters for your business.
If you like to know more about avoiding robustness issues, I'd love to point you to another of my blog posts. Unfortunetaly SCN would see this as a "grounds for rejection". That's why I removed the link.
Dumps are not your only friend. Google is, too.
