Search Results get_type




Overview
Explore in AI Chat

Overview

APP_EXCEPTION is a foundational exception-handling utility package in the Oracle E-Business Suite APPS schema. It provides a consistent mechanism for storing, propagating, and retrieving structured exception information across the EBS code base. Rather than relying solely on native PL/SQL error semantics, APP_EXCEPTION allows an application to raise a custom exception while simultaneously capturing a user-facing message and a numeric error code. This separation of exception control flow from diagnostic detail is central to the EBS error-reporting model, where the Forms layer, concurrent managers, and calling programs need to display meaningful messages rather than raw Oracle error numbers.

The package is declared with AUTHID CURRENT_USER, so it executes with the privileges of the calling schema. It defines two named exceptions, application_exception and record_lock_exception, bound via pragma exception_init to error codes -20001 and -0054 respectively. The latter maps to the standard Oracle record-lock error, allowing EBS code to treat lock contention as a first-class application condition.

Key Procedures and Functions

The documented public interface comprises six callables. Each is described below by purpose, without reproducing argument signatures.

  • RAISE_EXCEPTION — Stores exception information (type, code, and additional context text) in package state and then raises APP_EXCEPTION.APPLICATION_EXCEPTION. This is the primary entry point used to signal a business or validation error from within a program.
  • GET_EXCEPTION — Retrieves the stored exception type, code, and text together through output parameters. It is the counterpart to RAISE_EXCEPTION and is the object most commonly referenced by developers searching for "get_exception." It is declared with restrict_references (WNDS, WNPS, RNDS), making it callable from SQL contexts such as a SELECT.
  • GET_TYPE — Returns the stored exception type as a VARCHAR2. Like GET_EXCEPTION, it is pure with respect to the database and carries restrict_references pragmas.
  • GET_CODE — Returns the stored exception code as a NUMBER.
  • GET_TEXT — Returns the stored exception text as a VARCHAR2.
  • INVALID_ARGUMENT — Documented as part of the API surface and associated with argument validation failures raised by EBS utilities.

Tables Accessed

APP_EXCEPTION does not reference application tables. It is a stateless-with-respect-to-SQL utility: exception type, code, and text are retained in package-level PL/SQL variables rather than persisted to a database table. No APPS synonyms are listed as tables accessed in the documented metadata. As a result, the package imposes no DML footprint and its GET_* functions are safe to invoke from read-only SQL statements.

Usage Notes

Because of its ubiquity — the package is referenced by more than 3,800 other EBS packages — APP_EXCEPTION is effectively the standard error-signalling layer throughout Oracle EBS 12.1.1 and 12.2.2. A typical pattern is a program accepting an exception block that calls RAISE_EXCEPTION for validation failures, and a caller that catches application_exception and invokes GET_EXCEPTION or the individual GET_TYPE, GET_CODE, and GET_TEXT accessors to reconstruct the diagnostic message for display. Oracle Forms-based flows and concurrent programs rely on this mechanism so that friendly messages can be shown instead of raw error codes. Custom code should follow the same convention: raise through RAISE_EXCEPTION rather than raising a bespoke exception, and always populate the text argument to preserve context for downstream consumers.