Hi friends,
most of the time when your application does not work as you expected and you want to debug to find root cause. Unfortunately there is no hint in your application which can guide you to the right way of trouble shooting( if there is some error message poped up in ui, then you can quickly locate the exact location of the code which raises that error message using the approaches explained in my blog ). My personal opinion about the reason why we don't see any error messages in UI but the application still does not work is because that, at least in CRM web client ui development area, there are indeed some exception raised in the backend, however they are caught by the framework without any error handling ( at least the framework does not raise the error into UI or notifies developer with whatever ways ).
In this situation it is difficult for developers to find the entry point of debugging. If just starting to debug into framework, we may get lost in the horrible callstacks of framework code.
I will use a real example in my project to demonstrate how to leverage ABAP exception breakpoint to make our debug easier.
I developed a table using BSP in CRM. The content of each column is filled in the runtime by the getter method of the context node which is bound to a BOL node.
During my testing, I found the column "Associated Object" in the first row is empty. Hmmm, my first assumption is there must be something wrong with my implementation in its getter method GET_ASSOC_OBJ_DEF_ATTRIB.
So I set a breakpoint on that method and start debugging. To my surprise, I found the breakpoint is not triggered for the first row, but triggered as my expected for the left rows two, three, four.... Why the framework does not call the getter method for my first row? Then I planned to debug the BSP framework to understand how the getter method is called for my second row. After sometime's struggle against the framwork code, I changed my mind since I find it is not an effective way to debug the complex framework code.
I do believe there is some exception occured in the backend, but caught by framework. I set a breakpoint in search button implementation, since for sure the exception only occurs after search is executed.
I create a new exception dynamically. Since I don't know the exact name of exception, I can only create a breakpoint based on CX_ROOT, which is super class of all class based exceptions.
then all that I can do is just F8, F8 and F8... Soon ( ten seconds later) I found one exception raised in a suspicious method GET_TABLE_CONTENT.
Then I click "Display Trigger Location", the debuger displays the method GET_P_ASSOC_OBJ_DEF_ATTRIB which leads to the exception CX_SY_NO_HANDLER.
Wait.. isn't this trouble-maker method developed by myself?
After going through BSP framework code I learnt that BSP framework will first try to determine the cell type by calling our property getter method ( PREFIX GET_P_XXX). Only the successful determination of field type can trigger the successive call of content getter method ( PREFIX GET_XXXX) to retrieve the cell content.
By the way, if the method which trigger the exception is not owned by you, you need to know which class that method belongs to.
You can achieve it by using SE80->Repository Information System
Note: By setting a break point on the constructor of exception class CX_ROOT, we can achieve the same result. Thanks for the suggestion from adi.sieker.
- SAP Managed Tags:
