This is the second sub-post of a series, which outlines how to investigate a particular example/pattern of system dump caused by a programmming error.
Here it is about an incorrect call of BOPF methods from a custom enhancement: “A Finalize (save) is triggered although the piece of code runs already in after save context.” Again it is not obvious, you need to follow 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.
The system dump looks exactly the same as per the screenshots in the main post and in sub-post 1.
This time the application information might even tell the method/class indeed, but you don‘t understand why the system dumps…
As in the first example – the callstack in the ST22 dump does not help you any further for debugging a lower call stack level. Hence follow the steps of the sub-post 1 Example – until you can set a breakpoint in the method from where the initial exception is raised.
Rerun the example – then you see the real callstack from the point in time when the original exception was raised.
When navigating in the debuggers callstack to the method, which called the method set_application_error, you can investigate the root cause.
Here you see that the BOBF framework does not allow to trigger another save (finalize) and you need to find the one, who triggered it…
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