Browse Prior Art Database

Exception Handler that Determines Error Location

IP.com Disclosure Number: IPCOM000122772D
Original Publication Date: 1998-Jan-01
Included in the Prior Art Database: 2005-Apr-04
Document File: 2 page(s) / 133K

Publishing Venue

IBM

Related People

Borman, SD: AUTHOR [+2]

Abstract

An important aspect of any program is the way in which errors are handled. Examples of errors might be where the program attempts a divide by zero operation, or attempts to read or write to inaccessible memory (inaccessible for example because it does not exist, or has not been allocated to that program). The simplest outcome of such an error is that execution of the program terminates immediately, and the operating system outputs some error details (normally to the screen).

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 43% of the total text.

Exception Handler that Determines Error Location

      An important aspect of any program is the way in which errors
are handled.  Examples of errors might be where the program attempts
a divide by zero operation, or attempts to read or write to
inaccessible memory (inaccessible for example because it does not
exist, or has not  been allocated to that program).  The simplest
outcome of such an error  is that execution of the program terminates
immediately, and the operating system outputs some error details
(normally to the screen).

      If a programmer wants to know more details about an error, it
is common to use a debug facility.  This requires selection of a
special option at program compile time.  The program can then be
stepped through  in a debug environment, allowing the programmer
explicit access to the  point of execution, values of variables and
so on, even after the program crashes.  However, the compiled
versions of programs which are  distributed to customers are
generally not debug enabled, firstly to allow the compiler to
optimize performance for the product run-time, and  secondly to
prevent competitors from easily understanding the inner workings of
the program.

      A particular problem is how to provide remote support to
customers in the event of an error.  In such situations it is
important to learn details about the error.  However, writing the
error information  to the screen as is the standard operating system
approach is ineffectual, since customers seldom remember such complex
and obscure information.

      One way around this is for each function, when called, to write
some information to a log file.  Thus if the program crashes, the log
file can be used for diagnostic purposes, and the error can generally
be assumed to be located in the last function to write to the log
file.  The drawback with this approach however, apart from the
additional overhead of the log file, is that it does not assist if
the error occurs  in some third party software which is integrated
into the program (for  example in a dynamic link library).

      Sophisticated operating systems provide enhanced error handling
facilities.  For example, the OS/2* operating system from IBM*
Corporation allows a program to include a special error handling
routine (called an exception handler).  Thus when the operating
system detects an error or exception, such as the memory access
problem or attempted divide by zero described above, the operating
system does not terminate execution of the program, but rather
invokes the exception handler within the program, informing it of the
type and location of the error.  The exception handler can be used
for a wide variety of purposes; a typical routine might write the
error information (type and location) to a file for safe storage and
subsequent analysis, and then terminate the program in an orderly
fashion to ensure that program data structures are left in consistent...