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.

/wp-content/uploads/2014/02/page4_picture1_383925.png

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 callstack-level before, where the method set_application_error is called (b).

Rerun the users example. The debugger comes up.

(a):

/wp-content/uploads/2014/02/page7_picture1_383926.png

(b):

/wp-content/uploads/2014/02/page8_picture1_384002.png

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)

(a):

/wp-content/uploads/2014/02/page9_picture1_384003.png

(b):

/wp-content/uploads/2014/02/page9_picture2_384004.png

For any exception object doubleclick thepreviousvalue as often as possibleuntil there is no previous exception.

/wp-content/uploads/2014/02/page10_picture1_384017.png

/wp-content/uploads/2014/02/page10_picture2_384018.png

/wp-content/uploads/2014/02/page10_picture3_384019.png

For the “initial” exception of this chain, click on the /wp-content/uploads/2014/02/page11_exception_384024.png  link, which opens a new section on the bottom to show the code from where this exception was raised.

/wp-content/uploads/2014/02/page11_picture1_384030.png

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.

/wp-content/uploads/2014/02/page12_picture1_384044.png

/wp-content/uploads/2014/02/page12_picture2_384045.png

/wp-content/uploads/2014/02/page12_picture3_384046.png

(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…

/wp-content/uploads/2014/02/page13_picture1_384048.png

===========================================================

All posts of this series:

General info and steps in the main-post.

Sub-posts: 

  1. Simple but not obvious error in a custom enhancement
  2. Custom enhancement calls BOPF methods incorrectly
  3. Custom enhencement calls incompletely configured BOPF action

===========================================================

To report this post you need to login first.

1 Comment

You must be Logged on to comment or reply to a post.

Leave a Reply