This is the first sub-post of a series, which outlines how to investigate a particular example/pattern of system dump caused by a programmming error.
I start with a “Simple but not obvious error in a custom enhancement” and it can be detected by following the exception chain backwards.
Read first the introduction and general information in the main-post.
As described in the main-post, the information you get from the system dump in ST22 does not help you to identify the root cause, hence you like to debug. Prerequisite is certainly that you can reproduce the system dump. Otherwise exit here and try to gather more details from ST22 according to the guidance given in the main-post.
Set an external breakpoint in the method from where the dump is triggered. (a)
Or in simple cases (like here) you could set a breakpoint also one call–stack-level before, where the method set_application_error is called (b).
Rerun the users example. The debugger comes up.
Here you see that the framework catched an exception that was not handled before.
Open the exception object of concern by doubleclick.
(could be any exception in any other code place too)
For any exception object doubleclick the „previous“ value as often as possible – until there is no previous exception.
From the opened code section, you can (unfortunately) not see its call stack or any variable values. You need to set a breakpoint, save it and rerun the example.
(save this breakpoint and it will become an external breakpoint)
When rerunning the example, then you can finally debug the code of the method from where the original exception was triggered. Here certainly it is simple…
All posts of this series:
General info and steps in the main-post.
- Simple but not obvious error in a custom enhancement
- Custom enhancement calls BOPF methods incorrectly
- Custom enhencement calls incompletely configured BOPF action