Debugging - Expert Oracle Application Express - page 291

When debugging is turned on via the API, even at the earliest point possible, APEX will have already
completed some of the steps involved in rendering or processing the page.
If you compare the interactive data to the data that was gathered programmatically, you'll notice
there are a number of things that just don't get captured in the programmatic version. This shouldn't
concern you too much as what is missing is directly related to core APEX code and not code for which
you will likely be seeking to gather information.
However, one of the more important things that gets left out is the first line of debug information
which indicates the phase. This is easily remedied by following the ENABLE_DEBUG_MESSAGE call with
a call to LOG_MESSAGE, as shown earlier in Figure 6-21.
The same is true for the PROCESS phase as for the SHOW phase demonstrated above. When
enabling debugging programmatically, there will be some things that get missed. In most circumstances,
the missing data isn't significant enough to be concerned about; however, if you want to make sure you
get all the data relating to a page, you're likely to want to enable debug as part of the page phase that is
directly before the one you wish to capture.
For example, if you wish to capture all the details about Page Processing for a page, turn debugging
on during that page's SHOW phase. Alternatively, if you wish to capture all information regarding a
page's SHOW phase, enable debug as part of the processing phase of the page that branches to the page
in question. If debug mode is already enabled prior to reaching the desired phase, even if it was enabled
programmatically, the entire phase's information will be captured.
Instrumenting Your Own Code
While having access to the debug information APEX emits by default is helpful, there will inevitably be
times when you'll need deeper insight into what may be going on in code that you have written.
The APEX Debugging API provides methods to expand the depth of information being gathered.
This is especially useful when you're trying to understand what is happening within PL/SQL that might
be part of a Branch, Computation, or Process.
Logging Custom Messages
The LOG_MESSAGE and LOG_LONG_MESSAGE procedures are quite simple in signature; however, they
provide an amazing amount of flexibility and functionality when it comes to gathering information
about what's going on within your application.
The most straightforward use case would be one in which you might want to emit simple messages
which mark the steps a piece of PL/SQL might be executing. For instance, marking the purpose of a
simple code construct, like a loop, as in Listing 6-1.
Listing 6-1. Simple Code Demarcation Using LOG_MESSAGE
BEGIN
--
APEX DEBUG MESSAGE.LOG MESSAGE( P MESSAGE =>'START - INSERTING 10000 RECORDS...');
--
FOR I IN 1..10000 LOOP
INSERT INTO PERF TEST (guid1, guid2, guid3, created on)
VALUES (SYS GUID, SYS GUID, SYS GUID, SYSDATE);
END LOOP;
--
END;