Dumps are your friend. A different way of thinking.
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.
Couldn't agree more.
According my "doctrine", unexpected results should lead to dump and not to error message.
By unexpected results, I mean something that should never happen (inconsistencies, missing master data/infrastructure customizing, etc.) and not any applicative error.
Dumps are my enemies too, when the user absolutely had to output 120K or so bills yesterday, and the job kept dumping at 18th bill because some "twit" down the call chain, rather than letting me handle an exception and decide if I want to continue with 19th bill, asserts the equivalent of "Master data must always be correct" 😡
There will be maybe 1 out of 10000 users or even admins who will be able to figure out how to find the offending bill number in the dump and to exclude it from processing. Assert is better than just continuing running with wrong or missing master data, and I do write lots of them myself - don't get me wrong, but it should not be overused, and not in the code that has potential to become part of mass processing.
Cheers
Janis
In this case, the dump is not your enemy. The assert is. The dump was your friend - it showed you where the enemy was lurking - in a badly conceived assert.
The best solution is always to process everything and pass a list to the user with the wrong ones, isn't it? The way to get this solution run is our problem everyday. In case of fighting this problem I like dumps showing me what to change...
If the dumps get into the productive systems too often, there might be another enemy to fight... the quality-gate with all it's testing and stuff like that...
Sometimes there might be some we don't want to see of course 😉
Regards
Florian
I agree. The only thing i dont like if a program dumps is how it looks like for the enduser. He is controntated with technical stuff he dont understand. What the heck is "TSV_TNEW_PAGE_ALLOC_FAILED" or "GETWA_NOT_ASSIGNED" ? The good thing is, everything is rolled back to the last commit point. Bad thing is, user does not really know if he did something wrong or what else happened. The TSV_NEW_PAGE_ALLOC_FAILED or TIME_OUT could be presented a little bit more user friendly. In most cases, there are not enough ressources available when these errors pop up. Everything else is too cryptic for the user and the developer is still able to react on this and can get the details in ST22.
Good point.
It would have been nice if SAP allowed us to set custom "error page" (report) for end users.
I agree to this, I don't personally hesitate to code some MESSAGE TYPE 'X' in some OTHER case or wrong subrc values that should never be triggered. Even if the tests in development quality should reveal those cases I keep those dump trigger in the code. Of course I (try to) put a (as much as possible) user-understandable text in the error message.
I got the point of this post but let me be more specific.
Nice blog!
I've seen in productive code.
TRY.
....
CATCH cx_root.
ENDCATCH.
This was commented with an incident number, based on a dump. So that data is now corrupt (potentially), but at least the users don't see a dump!
Haha, this awesome. Another example passed my screen last week. Comment at the specific routine, which cuases the dump.
"Don't know yet, but at least, the user done something wrong!"
~Florian
Normally I don't comment! But I couldn't get better than this post. BTW my approach is "Hello dump! Where were you? Long time no see!!" 😀
Cheers!
Nice one .....
Well i agree with you. We make custom applications which somewhere & somehow fails in the testing phase & DUMP appears on the screen.
The reason behind it could be we as a developer think about to reach to the output what we has to provide & we come to the point of achieving that but somewhere we write a block of code that we don't think to handle because it won't trigger any exception or DUMP but somehow it proves us wrong.
"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."
This really makes sense....
So we may think that Error handling technique is somewhat like antibiotic medicine...
it can diagnose speedily but it produces some side effect(some cases)...
But software works well without error handling technique is only built by
better software development technique and getting DUMP is one of the part of it.
I Agree..
I wouldn't go so far as treating dumps as friends. Yes, I prefer a dump than code which silently sweeps dirt under the carpet (try / catch cx_root with no further action example above).
But, quoting you "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." If you're a good doctor, you should detect the not so visible symptoms (bad or no exception handling and proper messaging) when treating the patient for a minor issue (unrelated code change), and cure the patient if it's in your hands before the disease is terminal (dump).
I get the blog point, but I'm afraid some won't and may start calling methods or functions without specifying the EXCEPTIONS or TRY CATCH clauses, just because they don't know how to handle them (there lies the real problem).
Regards
Hi Alejandro,
you are right. Some developers will most likely not know how to handle exceptions.
But in my experience, the first step to improve one's skills is to understand one's limits.
Every mistake you made / dump you produce is a chance to understand that something's rotten in your ABAP.
I believe that most developers want to deliver quality. Once they identify limits in their skills, they can work towards improving.
Cheers,
Andreas
Totally agree with this: "the first step to improve one's skills is to understand one's limits."
"I believe that most developers want to deliver quality" This is where I disagree. I believe most people just want their code to activate and "not dump" so they can go home. That's why copy paste is so widespread. You can't improve if you're not interested on it.
That's a depressing perspective. Though probably true - which is why it is depressing!
A dump should not be your friend, as it means you - the developer - did something terribly wrong. If an error occurs that is caused by your program - ignoring now dumps caused by other means like out of memory, system crashes, etc - it's the task of the developer to treat it. In case your program is doing something important and crucial that can corrupt your data / database, try to catch possible errors and do a roll back. And give the end-user a nice error message explaining that monkeys are already dispatched to solve the problem.
Therefore, logs are your friend. Write the status of your program in a log. Monitor that log for error messages. These should contain enough information to show what went wrong. The problem is that you need to know how to write useful log messages. That's a little bit more complicated that to let the program create a dump. And of course you need how to monitor your logs / applications.
Isn't that exactly the purpose of ABAP dumps?
Why should you duplicate this log mechanism with custom one?
A dump shows you the state of the program when the error occurred. It does not tell how this state was triggered. When the error occurred because of an error 3 minutes before when the user entered some other data in sub-form X, you`ll need a log to understand what happened. Without, you`ll fix symptoms, not the cause.
And a log also shows you how your app is doing and being used.
OK. If I understood correctly, you are talking about an applicative (not technical) log.
I think that you need both: application log and ABAP (technical) dump log.
A log does not hinder you to write technical information into it. If you want, you can write variable values into it, everything that helps you to understand the state of the program in a certain execution step. The dump is then additional information helping to understand the actual error. But a dump without history?
The vast majority of the time I'm able to figure out what caused the dump directly. There is a huge amount of useful information in them if you know where to look.
In BI, DTPs and such fail without dumps - it increases the difficulty of error analysis quite considerably.
I don't think it is practical (or even possible) to write technical trace for each and every step in every program.
The only thing which might be sensible is setting logpoints in primary code blocks/methods (What wouldn't help in case of one-time dumps since they should be inactive by default).
Very Good Topic.. 🙂
I learned a lot in ABAP because of DUMP..
In initial days it was nightmare..
But nowadays I am expecting the dumps from Standard Programs to learn in-depth of ABAP..
Thanks,
Maruthamuthu Subramani
Hi Andreas,
I had liked your perspective in thinking Dumps as ABAPers Friend. I need to start thinking atleast in that manner from now onwards 🙂 .
Hi Andreas,
I do not agree at all - that's why:
Dumps are frustrating the user... (bad feeling 🙁 )
a) result is not intended outcome
b) effort on user input is waste
c) typically a message is not comprehensive/cannot be understood on business level
d) user has no clue what to do next
... and lead to user compensation (TCO 🙁 ) ...
e) all users have to interrupt regular business processing
f) most users search for work-arounds on business level for some "meantime"
g) technology-friendly users start to learn about application domain at code level
h) users have to open up internal tickets that may end up in OSS messages
i) key users and administrators have additional efforts for provisioning of those help desks
... s.t. everybody knows stories from complaining users/key users/power users/administrators...
j) management and decision takers are influenced by "bad quality" notions
k) SAP's reputation in respect to reliable system provisioning does not increase as possible / decreases
Get me right: I do not say that streets were wet because of a single rain drop. But it contributes!
To sum it up:
Agree: Fault-tolerance leads to complex wrap-up processes.
Agree: In unforeseen cases the corresponding effort is up to our customers (TCO 🙁 )
Agree: A system must have means to protect itself.
Disagree: A dump is AT NO TIME the appropriate message to the end user.
I suggest that messages, including error messages, especially those to unexpected situations within an application shall be regarded as part of user interaction with some output on UIs. Why should a UI's beautiness not include system responses?
From my experience, this requires a mapping from "technical stuff" to information on business level. Further, this leads to more efforts in development and by-passing customer information to developers. So we should think about effects on information hiding by silo (Chinese whisper), and about the value-adding of messaging concepts supported by architecture.
So I consider MESSAGE + DUMP are not our friends at all.
Regards,
Martin
P.S.: Personally, I like asserts and exceptions that will prohibit any COMMIT_WORK or triggering system-/process-external communication. In ABAP, I often use class-based exceptions that may lead to "rollback only" state(s) within a centralized LUW control. Derived message(s) must never ever be just absorbed by consuming code. My expection is that triggered "message(s)" have to be transformed which enables the end user to see system failure within his/her UI with potentially user input still available:
P.P.S.: Of course, there are limitations within ABAP stack s.t. we cannot avoid dumps in each and every case. Example: There is no memory control. In case of memory exceed, a dump cannot be avoided by program. However, this should not be a wild card for use cases where limitations won't apply.