Search Results debug_exc




Overview

APPS.PO_DEBUG is a PL/SQL debugging and diagnostic utility package owned by the APPS schema in Oracle E-Business Suite. It provides a standardized set of logging, tracing, and error-handling routines used primarily by Oracle Purchasing and related modules. Within the ETRM classification this object is registered as an OTHER API, meaning it is not a business-document API invoked by external integrations but rather an internal developer utility. The package header explicitly notes that its logging routines are obsolete and have been superseded by the PO_LOG package; the source header block directs developers to the internal logging standards documentation for the current strategy. Despite this deprecation notice, PO_DEBUG remains present in 12.1.1 and 12.2.2 and is still referenced by a large number of dependent packages—111 according to the documented metadata—making it a legacy but widely entangled component of the Purchasing code base.

The package offers conditional debug gating, structured statement and variable logging, exception tracing, and output redirection. It exists so that Purchasing developers can instrument code, capture diagnostic output during debugging sessions, and handle unexpected errors uniformly without embedding ad hoc DBMS_OUTPUT calls throughout application logic.

Key Procedures and Functions

The 25 documented routines fall into functional groups:

  • IS_DEBUG_STMT_ON / IS_DEBUG_UNEXP_ON — Boolean functions that report whether statement-level debugging and unexpected-error debugging, respectively, are currently enabled. Callers use these to avoid unnecessary logging overhead.
  • DEBUG_STMT — Writes a single diagnostic statement consisting of a log heading, token, and message.
  • DEBUG_BEGIN / DEBUG_END — Mark entry into and exit from a logged code block using a log heading.
  • DEBUG_VAR — Overloaded routines that log named variable values, with variants accepting VARCHAR2, NUMBER, and DATE data types, plus a progress indicator.
  • DEBUG_EXC / DEBUG_ERR — Log exception and error information. DEBUG_ERR is the routine most directly associated with the user's search term "debug_err" and is the conventional entry point for recording error conditions in the debug stream.
  • DEBUG_UNEXP — Records unexpected errors.
  • HANDLE_UNEXP_ERROR — Centralized handler for unexpected error conditions, typically invoked from exception sections.
  • DEBUG_TABLE — Dumps tabular data for inspection, supported by the public G_ROWID_TBL and G_COLUMN_TBL variables declared for convenience to callers.
  • DEBUG_SESSION_GT — Supports session-level debug state, typically backed by a global temporary table.
  • WRITE_MSG_LIST_TO_FILE / PUT_LINE / SET_FILE_IO — Output management routines that write buffered messages to a file and control file I/O behavior, allowing debug output to be redirected away from DBMS_OUTPUT.
  • G_ALL_ROWS — A constant inherited from PO_LOG.c_all_rows, used as a sentinel value for "all rows" in table-dump operations.

Tables Accessed

The only documented table reference is DBMS_OUTPUT, accessed through an APPS synonym. This confirms that the package's default output channel is the Oracle DBMS_OUTPUT buffer, which is consumed by clients such as SQL*Plus, TOAD, or the concurrent manager log when SERVEROUTPUT is enabled. The package also declares PL/SQL collection variables (G_ROWID_TBL and G_COLUMN_TBL) in memory for the table-dump facility, and references a session global temporary table for session-level debug state. No persistent application tables are documented as being read or written, consistent with its role as a diagnostic utility rather than a data-processing component.

Usage Notes

PO_DEBUG is invoked from within other PL/SQL packages, not from Forms or concurrent programs directly. Its 111 dependent packages indicate that it is called throughout Purchasing's procedural code, particularly in exception handlers where DEBUG_ERR and HANDLE_UNEXP_ERROR are conventional. Developers enable debugging through the gating functions before calling the logging routines, and may use SET_FILE_IO to redirect output to a file when DBMS_OUTPUT is impractical, such as in concurrent program execution. Because the header declares the logging routines obsolete in favor of PO_LOG, new development in 12.1.1 and 12.2.2 should use PO_LOG for logging. However, PO_DEBUG must be retained for backward compatibility with existing dependent code, and any custom code referencing it should be evaluated for migration to the PO_LOG API.