Enhancing the APEX Debugger

Matt Mulvaney Aug 21, 2019 10:45:29 AM

One minor inconvenience when using the APEX debug features is the amount of noise which fills up the debugger when I try to find my debug messages.

For example, I have the following Before Header Process. Line 2 calls a DB procedure.

Code Editor - PL SQL Code

create or replace procedure

When I review the debugger I see dozens of APEX framework messages which I’m not currently interested in. I then have to zoom up and down trying to locate my custom debug messages.

debug message data - google chrome

Sometimes I insert some text e.g. Matt and then use the browser search features to find the debug messages at that point.

Is there a better way?

I’ve evaluated several approaches to this and I’m going to blog about just 2 methods. Each method works by getting the debug IR to highlight the row containing the custom debug message. Each method has its own pros and cons – so if you would like to use one of these methods then please weigh-up the factors and decide for yourself.

The main problem faced here is getting the debug IR to recognise which message is custom and which is framework

Method A: Log Level 3

The simplest way is to message at log level 3. This is achieved something like the below

code editor - PL SQL Code

Then you just need to add this highlight rule to debugger

Highlight

Click Apply, and suddenly your custom debugger messages leap off the page.

debug message data - google chrome (1)

You can also save the report as a public report.

I mentioned there were cons:

  1. Unfortunately, debugging at level 3 is unsupported as it is a reserved level. In a future release of APEX, this functionality to log at level 3, could be removed. Although logging at Level 3 is much beneficial than logging at level 1 or 2 because those levels force a debug entry even though debugger is disabled.
  2. There is a slight overhead to typing p_level >= 3 to each debug message. You could write your own procedure (e.g proc_log_message) instead which calls apex_debug.message with the log_level 3 parameter

Method B: Prefix Method

First decide on a character which would never appear as a first character in a debug string. For this example, I’m going to pick the ~ symbol. Then you would prefix your debugger statements with this symbol.

prefix method-1

In debugger; you’ll have to change a few extra things

Step 1: Create a Compute Column as per below

create a compute column

Step 2: Deselect the Message Column and ensure the **Message column is below Execution as per below

select columns

Step 3: Add a Highlight rule as per below

Add a highlight rule

You can even extend the compute columns a little further: for example, whenever I debug in server side code I’m going to use the ó prefix which I obtained by holding ALT GR + O

Extending the compute columns

In this case I need to change my compute column to

CASE WHEN INSTR(B,1,1) IN (‘~’,’ó’) THEN SUBSTR(B,2) ELSE B END

The final result being

Changing the compute column

On to the Cons

  1. Although there are no unsupported features used in this method, it seems unnatural using the prefix method. It would be advantageous to use your own procedure as described in method A
  2. If there’s a chance of that a prefix-character should occur naturally, then its will be stripped off using this method
  3. You’ll lose the monospaced font which only applies to the non-computed Message column

Summary

Overall, using these techniques can enable developers to quickly locate debug message by row-highlighting. Each method has its pros and cons. I hope that in newer released of APEX we’ll get that additional column indicating which is a custom message and which is a framework message – that way it would be much clearer and easier to apply IR row highlighting.

If you prefer option A, then I would advise using your own procedure which was a wrapper to apex_debug.message. If debugging at log level 3 stops working in a future version, then it’s just a case of converting your wrapper procedure to the prefix method.

 


 

Author: Matt Mulvaney

Job Title: Senior Oracle APEX Development Consultant

Bio: Matt is an experienced APEX solution designer having designed numerous complex systems using a broad range of Oracle Technologies. Building on his previous experience of Oracle Forms & PL/SQL, he is entirely focused on providing functionally rich APEX solutions. Matt promotes APEX as a software platform and openly shares best practises, techniques & approaches. Matt has a passion for excellence and enjoys producing high quality software solutions which provide a real business benefit.