Term fly presents http error occurs one your blocks

Term Fly Presents http://www.flyheart.com

When an error occurs in one of your PL/SQL blocks, it's often useful to determine the values of persistent package variables at the time of the failure. You can do this to some extent with the debuggers available with many IDEs. That approach doesn't, however, give you access to the data values within a user's application session.

This package (provided by Dwayne King, ace reviewer and PL/SQL developer) keeps track of the call stack by recording in a PL/SQL table each piece of code as it "announces" itself. It then uses that stack to determine which dump methods need to be called when an error occurs.

Unfortunately, there's no reliable (and supported) way right now to easily determine which packages "have state" even if they aren't in the call stack, but this may be possible in the future. Another straightforward exercise is to extend this package to write to a log file or pipe instead of just using the standard DBMS_OUTPUT package.

The proc1 procedure sets the module name in the stack, assigns a value to a variable, and then calls proc2, which also "announces" itself and modifies a package variable. It then, however, raises an EXCEPTION:

PROCEDURE demo_pkg.proc1 IS
BEGIN
--announce entry into this module
error_pkg.set_module_name ('demo_pkg.proc1');

error_pkg.remove_module_name;
EXCEPTION
WHEN OTHERS
THEN
error_pkg.set_err_msg ('DAT023');
error_pkg.raise_error ('Failed Operation'); END;

The instantiation procedure passes the values of the package data (the package state) to the error package:

Benefits

94