Dynamic error lookup handler hierarchy

Details Dynamic error lookup handler hierarchy Dynamic error lookup handler hierarchy

1995-12-27

2002-07-16

Oberley, Alvin E. (Department: 2151)

Electrical computers and digital processing systems: multicomput

Computer-to-computer data routing

Least weight routing

C709S241000, C714S038110

Reexamination Certificate

active

06421740

ABSTRACT:

BACKGROUND OF THE INVENTION
The present invention relates generally to computer systems. More particularly, the present invention relates to improved apparatuses and methods for processing software error messages in a computer system.
Software errors are errors that occur in the course of a program's execution. In the prior art, there exist many methods for handling software errors when they occur. In one exemplary prior art method, software errors are handled by the computer operating system, which is endowed with programmed instructions to, for example, alert computer users of the problem encountered. By way of example, the operating system may detect that an out-of-memory condition has occurred and may communicate the error to the application program so that the application program may alert the user with an appropriate message using a generic error number such as “Error-28.” By referencing the operating system user's manual, for example, the user would then be able to interpret the meaning of the error number and perhaps take appropriate corrective actions.
In a more advanced prior art system, developers of computer applications provide application-specific error lists, each of which contains a multiplicity of error numbers and their associated messages.
FIG. 1
illustrates an application error list
100
, which is utilized by an application program
102
to interpret the error numbers to generate error messages. By referencing its error list, an application program can provide the user with error messages that are more relevant in the context of the application program in which the error occurs.
By way of example, the above error number “28” (out of memory) may be decoded by a word processing application program (via its error list) into a message stating “too many characters in document.” In a spreadsheet program, the same error number may be decoded (via the spreadsheet's error list) into a message stating, for example, “too many columns in spreadsheet.” Similarly, a graphics application may process an out-of-memory error number or code into, for example, “too many colors.” These messages, being specific to their application program, provide more meaning to the user than the above-mentioned generic error number (“Error-28”), i.e., the message that would have been generated had the operating system handled that error.
Application-specific error lists work well for application-centered, i.e., monolithic, applications. To elaborate, application-centered programs generally consist of data-handling codes to manage a predefined set of data types. A given monolithic document processing application program may contain codes to handle, for example, text and graphics. That monolithic application, however, would not be able to render and manipulate spreadsheet data or audio data that a user may wish to incorporate into the existing document at a later date. This is because application-centered programs cannot handle data types that are unknown to the program at the time of its creation.
The aforementioned limitation, among others, gives rise to a new type of software technology, i.e., one that is not application-centered. This new technology, referred herein as component-based architectures, allows different types of data to be rendered and manipulated within a given framework irrespective whether the framework is originally programmed to handle those types of data. In a component-based architecture, multiple data types may be embedded within the aforementioned framework, with each data type being rendered and manipulated by its own executable unit. Representative existing component-based architectures include OpenDoc™ by Apple Computer, Inc. of Cupertino, Calif. and OLE™ by Microsoft Corporation of Redmond, Wash. For further information regarding component-based architectures (e.g., OpenDoc™ by Apple Computer, Inc. of Cupertino, Calif.) reference may be made to, for example, commonly-assigned, pending patent application U.S. Pat. Ser. No. 08/175,549, now U.S. Pat. No. 5,745,910, entitled “Frame Structure Which Provides an Interface Between Parts of a Compound Document” which is hereby incorporated by reference.
The traditional approach to component-based architectures, however, may not enable the computer to provide a computer user with meaningful error messages when an error occurs in connection with a newly embedded data type. To facilitate a discussion of this problem, a compound document, representing one specific implementation of the aforementioned OpenDoc™ component-based architecture, is discussed below. It should be borne in mind, however, that the component-based architecture is not limited to only document processing programs and may be extended to implement any type of computer-implemented task.
FIG. 2A
shows a prior art component-based compound document framework
202
having various embedded component data and corresponding executable units. An executable unit generally comprises the binary code that is responsible for executing, manipulating and rendering the component data. In this example, the embedded component data comprise a text component
200
, a graphics component
204
, a spreadsheet component
206
and an arbitrary component
208
, representing an arbitrary data type. Arbitrary component
208
is included herein to show that any type of arbitrary data may be embedded within framework
202
and utilized as long as it is provided with its own associated executable unit. Additional components may be embedded in framework
202
of
FIG. 2A
as desired.
There are further shown in
FIG. 2A
focus frames
212
,
214
,
216
and
218
, corresponding to text component
200
, graphics component
204
, spreadsheet component
206
and arbitrary component
208
respectively. As the terms are used herein, “frame in focus” or “focus frame” denote the area within framework
202
that contains an embedded component. A component becomes the component in focus when a pointer is moved into its associated focus frame, followed by a selection command, e.g., by clicking on a mouse or other suitable user interface commands (i.e., while the executable unit for that component is currently executing).
In
FIG. 2A
, focus frame
212
contains embedded text component
200
, which is rendered and manipulated by executable unit
224
. Focus frame
214
contains embedded graphics component
204
, which is rendered and manipulated by executable unit
233
. Within graphics component
204
, there is further embedded a color adjustment component
241
and associated focus frame
240
. Color adjustment component
240
is rendered and manipulated by executable unit
227
and may be employed to, for example, modify the number of colors with which the graphics data within graphics component
204
is presented. Color adjustment component
241
is shown herein to illustrate that multiple levels of embedding are possible.
Focus frame
216
contains embedded spreadsheet component
206
, which is rendered and manipulated by executable unit
235
. Likewise, focus frame
218
contains embedded arbitrary component
208
, which is rendered and manipulated by its associated executable unit
230
.
In the prior art, framework
202
of
FIG. 2A
may also be provided with a comprehensive error list
209
designed to process the aforementioned generic error numbers when an error condition is encountered. However, the creator of framework
202
has no way to anticipate all the possible types of data, present and future, that a user may embed into a framework. Because of this, there may be situations in which a new component data that is unanticipated by the framework developer becomes embedded. If an error occurs while this new data type is manipulated, i.e., while the executable unit associated with that new data type is executing, the prior art error list may fail to provide an error message that is specific enough to be useful to the computer user. In this case, the user may be presented with the only error message the computer knows, e.g., the aforementioned error number message “Error-28

Affiliated with

Also associated with

Rating

Dynamic error lookup handler hierarchy does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Dynamic error lookup handler hierarchy, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Dynamic error lookup handler hierarchy will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-2905764