CA2235838A1 - Hierarchical error reporting system - Google Patents
Hierarchical error reporting system Download PDFInfo
- Publication number
- CA2235838A1 CA2235838A1 CA002235838A CA2235838A CA2235838A1 CA 2235838 A1 CA2235838 A1 CA 2235838A1 CA 002235838 A CA002235838 A CA 002235838A CA 2235838 A CA2235838 A CA 2235838A CA 2235838 A1 CA2235838 A1 CA 2235838A1
- Authority
- CA
- Canada
- Prior art keywords
- error
- application
- message
- messages
- server
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/079—Root cause analysis, i.e. error or fault diagnosis
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0766—Error or fault reporting or storing
- G06F11/0775—Content or structure details of the error report, e.g. specific table structure, specific error fields
Abstract
Error reporting may be enhanced by utilizing a programming language, such as C++ and its attendant enhanced error reporting facility. The invention generates an error message at the function level where the error occurs, as well as noting the line of source code during which time the error occurred.
The resulting populated error message (82) is then rolled up toward the main program (20). At each preceding roll up level, an additional error message (90) is populated which notes the original error message (104) information as well as adding return path information. Thus, after completed roll up to the main program (20), stacked error messages (76) are made available to the user (10) that fully define the complete path involving the error (80), in addition to the identification of the source code line where the error occurred.
The resulting populated error message (82) is then rolled up toward the main program (20). At each preceding roll up level, an additional error message (90) is populated which notes the original error message (104) information as well as adding return path information. Thus, after completed roll up to the main program (20), stacked error messages (76) are made available to the user (10) that fully define the complete path involving the error (80), in addition to the identification of the source code line where the error occurred.
Description
CA 0223~838 1998-04-24 W O 97/19403 PCT~US96/18201 ~ll~,RARCHICAL ERROR REPORTING SYSTEM
Fiel~l of t*e Invention The present invention relates to colllpuL~l error reporting systems, and more particularly to such a system that tracks and reports the software path traversed by an error generated during the running of a software application.
Background of the Invention Error code generation is an important aspect of running computer software ~hereinafter referred to as "applications"). Even operating systems generate error codes or phrases when an abnormality is ~letectf ~1 during operation of the software.
Typical error messages in applications may include a message in~lic~ting that a 10 particular requested file has not been found. Similarly, in an operating system, error messages are presented to the user, such as in the instance where a comm~n~l iS
entered by the user that is not recognized by the operating system.
A primary disadvantage of present error reporting systems, in applications and operating systems, is the lack of fully identifying where in the program (e.g., line of 15 source code) the error was detected. This would enable programmers to review the source code and quickly concentrate on the cause of the error, based on its occurrence at a particular point in the program. Further, the same error code may be returned during various subroutines or functions, during an application, so that no unique correspondence between the error and the function/subroutine exists. This20 makes it more difficult to troubleshoot problems when running applications.
The problem becomes multiplied when a main program accomplishes its processing by relying upon modules, in the nature of functions and subroutines, that themselves rely upon a library of software services. By way of example, a soft~,vare function may include an application comm~n~l to retrieve a file. Services relate to 25 underlying surfaces such as OLE which provides a software transport for importing data from one particular application, such as Excel~ into a second application, such as WordTM. Since the same service may be employed by various functions and CA 0223~838 1998-04-24 WO 97/19403 PCT~US96/18201 subroutines, the generation of a simple service error message is not terribly useful since it does not uniquely identify which branch of the application was involved.
Accordingly, a need exists to track and report errors with greater detail than that currently available.
Brref Descrzption of the Present lnventwn The present invention anticipates the rewrite of existing applications, or the gellel~,Lion of new applications lltili7in~ progr~mming languages that permit the generation and relaying of detailed error mf~cc~ges (heieillafLer referred to as"exceptions") that identifies a line of source code where the error is generated, as well as the path traversed by the exception on a return of the resulting error message to a user's display.
This is accomplished by generating a m~sc~ge, upon the occurrence of an exception, the message being populated with fields that define where the error occurred. This message is then relayed through subsequent application functions as part of a return path to the main program and subsequently to the user's display.
Once an error mess~ge is generated at one particular function layer, each subsequent functional layer affected generates its own m~sc~ge identifying the location of that subsequent function layer. The end result will be a stacking of these error mes.c~es, relating to an exception detected along the return path to the main program.
In this manner, the return path is completely identified since path data has populated fields of respective error messages, created at each affected functional layer. Part of the information includes the line of source code affected when the error was detected.
This level of detail in error reporting is stored for troubleshooting. It is most helpful to detect whether the error occurred as a result of a "bug" in the program itself, or whether it was most probably introduced as a result of user error.
CA 0223~838 1998-04-24 Certainly, the generation of hierarchical error reporting is extremely useful during development of a software application.
Brief Description of the Figures The above-mentioned objects and advantages of the present invention will be more clearly understood when considered in conjunction with the accompanying drawings, in which:
Fig. 1 is an archit~ctllral block diagram of a generalized computer system platform.
Fig. 2 is a hierarchical flowchart of a program in~ ing the two principal 10 layers of application and underlying software layer, namely, services.
Fig. 3 is a basic block diagram of a client-server ellvho~ ent involving database management.
Fig. 4 is a flowchart inflic~ting a typical prior art exception (error) h~n~linp;
process between functions of an application.
Fig. S is a flowchart, similar to Fig. 4, but indicating a hierarchical exception h~ntlling, as employed in the present invention.
Fig. 6 is a layout of an exception message, indicating typical fields to be populated with detailed error message information, as employed in the present invention.
Fig. 7 is flowchart, similar to that of Fig. 2 but indicating additional hierarchical error reporting, as contributed by the present invention.
Fig. 8 is a flowchart of a sequence of normal operation of a program wliLL~n in a language such as C + + .
Fig. 9 is a flowchart similar to Fig. 8, with operation of error h~ntlling 25 depicted.
CA 0223~838 l998-04-24 W O 97/19403 PCT~US96/18201 Detailed Descript~on Of The Invent~ion Fig. 1 is a generalized architecture of a personal co~ uL~l (PC). A user 10 relies upon a software program or application 12 to process data (for example, in a word processing program such as WordTM by Microscoft). The PC system is 5 controlled by an operating system 16, such as DOS~, Windows~, etc. The hardware of the col~uL~I 18 carries out the various processes required by the application and the operating system. Often times, an additional layer, indicated as services 14, interfaces with the application. For example, if data from the coll,~uLel software Excel~, by Microscoft, is to be inserted into a document being prepared in Word~, 10 an underlying service, such as the conventional service OLE may be required. Any of the boxes shown in Fig. 1 may generate an error. The purpose of the present invention is to report back, with detailed particularity to the user 10, an error report that identifies the path of the error as well as the line of source code where the error was encountered. R~ir~lly, in order to achieve this function, and as will be 15 explained hereinafter in greater detail, this requires the generation of an error message in the layer where the error is introduced. Subsequently "touched" levels in the return path of the error, to the user, generate a separate error mes~ge identifying each respective layer in the return path. The end result is a stacking of error messages that completely define the error and the return path of the error. The 2 o error messages created avoid the ambiguity that results from present error reporting systems where a similar error can occur in parallel branches so that a returned error does not fully identify the particular branch affected.
~ or example, in Fig. 2, the hierarchy for a prior art architectllre involving a software application and ~tten~1~nt services is depicted. More particularly, a main 25 program 20 controls subroutines 24 and 26. The main program also controls a function 22 which may be a simple comm~n-1 from the user 10, such as a retrieve file function, or similarly a read function of a ~l~t~ e record. As the hierarchy diagram of Fig. 2 indicates, the function 22 and subroutines 24, 26 may each cooperate with various services 28-35. As a reminder, "services" is used in the context of an CA 0223~838 l998-04-24 W O 97/19403 PCT~US96/18201 underlying software layer such as the case of OLE, as previously explained in connection with Fig. 1. Function 22 again refers to an application comm~n~l, such as retrieve a file or read a ~1~t~b~e record. Typically, software applications include a library of functions, any of which may be the particular function indicated by block 5 22 in Fig. 2.
In order to understand the limit~tions of the prior art reporting systems, consider more than one of the services 28-35 as generating an error message. Theerror message is reported back through a respective preceding level (function 22, subroutines 24, 26) to the main program 20. The user is informed as to the error~
0 which is typically a code or short phrase. However, since multiple branches from the main program invoke the same service, it would be impossible to determine through which path the error mçss~ge was returned.
The present invention solves this problem by keeping track of the path through which an error message is "rolled up" to a top level, namely the main program. The 5 error message, as will be developed hereinafter, not only develops informationconcerning the path through which the function error is returned, but also in-lir~tes which line of source code was being operated upon by the main program during thegeneration of the error. Such a reporting system is of great advantage during operation of the system, so that it may be determined whether a user is introducing the error, or whether a software problem exists. Usefulness in ~ietecting the latter mentioned problem is of particular importance during the debugging of applications during development.
In order to accomplish the objectives of the present invention, an application must be written (or an existing application rewritten) in a progr~mmin~ language that provides a tool kit sufficiently extensive to allow the types of error message generation presently required. Thus, in a preferred embodiment of the present invention, the known pro~ nl .lil~~ language C + + is employed.
CA 0223~838 1998-04-24 WO 97/lg403 PCTnJS96tl8201 To further explore the usefulness of the present invention, ler~lellce is made to Fig. 3 which shows a typical client-server environment for ~l~t~bz~e applications 40, 42 and 44. Typically, a user 36 monitors a display, which may be a graphicaluser interface (GUI) 38 (e.g., Windows~. This represents a data presentation layer for the user. The client is provided with a local ti~t~h~e 46 which is constantly refreshed during system operation. Col"~ ic~tion between the client and server occurs at a co~ lullication interface including a me~.c~in~ layer 48 at the client and a corresponding mess~in~ layer 50 at the server. The main rl~t~h~e 52 at the server is the source of the complete database. In typical applications, m~c.~ging may occur o by llfili7ing TCPIIP protocol.
In the system of Fig. 3, the user requests records from the main datahase 52.
During such an operation, if an error mess~ge were created, the local (1~t~ce 46would return a message in~ir~ting that the record could not be found. However, there would be no information as to which aspect of the coll~llunication chain actually caused the error. The pro~ ll",-i,-g language C~ + includes exception h~n-lling capabilities (error me~ges) and by virtue of the present invention, the language's exception h~n~llin~ is augmented, in a manner heretofore unknown, so as to add error path tracking. Thus, in the example discussed in connection with Fig. 3, the presentation layer 38 would enable the user to specifically track where in the c-~".~ iC~ion chain the error occurred, and which application was involved, including source code line identification.
Fig. 8 represents the normal flow of control from function to function in a program Wl iLIen in C + +, when there are no errors . In the Figure, Function A calls Function B. This results in a transfer of control to the beginning of Function B. At some time in its proces~ing, Function B calls Function C, resulting in a transfer of control to the beginnin~. of Function C. Function C calls no additional function and executes from beginning to end. When Function C has completed execution, controlis transferred back to Function B, which continues exec~ltin~, starting at the CA 0223~838 1998-04-24 instruction following the call to Function C. Function B then completes execlltin~
and returns control back to Function A. Function A resumes execution starting at t_e instruction following the call to Function B. Function A then completes executing and returns control to its caller (which could possibly be the operating system if 5 Function A is the "main" or topmost function in the application). Even though each function has "exception h~n-lling code", the code is never invoked since no error occurred.
Fig. 9 represents the same application as the previous Fig., except that, in this case, Function C detects an error during its proces~ing. When Function C "throws"
0 an exception, control transfers to Function B. In this case, however, instead of execution resuming in Function B at the instruction following the call to Function C, execution now transfers to the exception h~nrlling code that is part of Function B.
If this code passes the exception back up the chain ("rc~uow~i" the exception), then control transfers to the exception h~n~llin3~ code t_at is part of Function A.
Thus it is seen t'nat, typically, function execution does not occur sequentiallyin the sense that Function A completes processing followed by Function B, followed by Function C. Instead, Function A hlt~ll u~ts itself to call Function B, which in turn inlell u~ts itself to call Function C. When the lowest called function is complete, the next lowest function is then re-entered and allowed to complete. And so it goes, up 2 o and down the chain of function calls.
A further exploration of normal exception h~nrlling by C+ + is inrlic~te-l in Fig. 4, which does not include t'ne augmentation of the present invention. ~n Fig. 4, a portion of an application is indicated, employing C+ +, wherein four sequential Functions A-D (56-62) are shown. For example, if an exception 64 was "thrown"
25 (reported) by Function D, that exception is "caught" (received) by the previous layer C. As int1ir~cl in Fig. 4, tne exception is "rolled up" through prior Functions (A-C) (66, 68), thereby completing an error reporting process. However, although CA 0223~838 1998-04-24 the nature of the error may be identified, its particular path from Function D-A will not be derived.
Fig. ~ indicates the st~rking of exceptions so that the entire return path of anexception may be recorded. In accordance with the present invention, if Function D
throws Exception 1 (at lerelellce numeral 70), a message will be generated int1ic~ting that Function D is found to be in error and what line of source code was effected.
This message corresponds to Exception 1 (lerelellce numeral 70). The thrown Exception 1 is caught by Function C which generates its own message acknowledging the previous mes~ge. Thus, Exception 2, thrown by Function C (72), repeats the o information that Function D was found to be in error and that Function D was called from Punction C. Further, the line of source code, where the error occurred, is repeated.
Reference numeral 74 in Fig. S in~ tes the contimle-l rolling up of ~.xceptions 1 and 2 to the prece~ling Function B. Again, the error messages are stacked, with the Function B adding its own error message to repeat the previousinformation and adding the inforrnation that Function B called Function C.
Fig. 6 indicates the stacking of two exception (error) messages 76 and 78.
Block 76 indicates the typical types of fields that would be included in an exception generated by C+ + . These would typically include a text message, corresponding to the error. The file name indicates the original source file cont~ining the function generated error. The function or function module name is next included. The linenumber in the original source code is similarly listed. If an error code is generated from the applicat;on itself, for example error codes in a word processing or ~l~t~b~e program, the error code would be included, as well. A field is also available for explanatory information relative to the error (variable string information). Another field may include an alternate error code, which, for example, may be a programmer's own error code.
CA 0223~838 1998-04-24 3 PCTAJS96/~8201 In operation of the present invention, Fig. 7 indicates a software flow diagram with enhanced error reporting, as compared with the prior art of Fig. 2.
Thus, as shown in Fig. 7, if an error is ~letecte-l at step 80, between the mainprogram 20 and the function/sul~l~3uLille steps 22/24, 26 an exception is generated and 5 an error message 82 is populated, with the information in~ te~l in Fig. 6.
If no error occurs, the application continues with the appropriate function or subroutine. If an error is ~etecte~l during function 22, the error step 84 will populate an error message 90, and this is rolled up toward the main program by st~-king asecond error message 82 for completing the roll up path information. Similarly, if 0 errors occur during subroutines 24, 26, corresponding error steps 86 and 88 will populate an error me,cs~ge 90. In the example illustrated in Fig. 7, if no errormessages occur at the conclusion of the function or subroutines, various services 28-35 will occur.
An error during the first executed service will cause completion of a 5 corresponding error step 92-102, thereby causing the population of an error message 104 at this level. As in-lir.~t~f~ in Fig. 7, an error message 104 will be stacked with error mec~ges 90 and 82 during roll up of the error m~ss~ge to the main program 20. If no error occurs, the application may be returned to the main program 106.The end result of error reporting is the stacking of error messages to complete the information concerning return path and source code line number.
Therefore, by virtue of the present invention, software applications may be written (or lcw~ ell) in a progr~mming language such as C + + with enhanced error reporting as compared with the prior art. Full information concerning error path and source line identific~tion expedites error detection and correction in software that is being developed or thereafter.
It should be understood that the invention is not limite-l to the exact details of construction shown and described herein for obvious modifications will occur to persons skilled in the art.
Fiel~l of t*e Invention The present invention relates to colllpuL~l error reporting systems, and more particularly to such a system that tracks and reports the software path traversed by an error generated during the running of a software application.
Background of the Invention Error code generation is an important aspect of running computer software ~hereinafter referred to as "applications"). Even operating systems generate error codes or phrases when an abnormality is ~letectf ~1 during operation of the software.
Typical error messages in applications may include a message in~lic~ting that a 10 particular requested file has not been found. Similarly, in an operating system, error messages are presented to the user, such as in the instance where a comm~n~l iS
entered by the user that is not recognized by the operating system.
A primary disadvantage of present error reporting systems, in applications and operating systems, is the lack of fully identifying where in the program (e.g., line of 15 source code) the error was detected. This would enable programmers to review the source code and quickly concentrate on the cause of the error, based on its occurrence at a particular point in the program. Further, the same error code may be returned during various subroutines or functions, during an application, so that no unique correspondence between the error and the function/subroutine exists. This20 makes it more difficult to troubleshoot problems when running applications.
The problem becomes multiplied when a main program accomplishes its processing by relying upon modules, in the nature of functions and subroutines, that themselves rely upon a library of software services. By way of example, a soft~,vare function may include an application comm~n~l to retrieve a file. Services relate to 25 underlying surfaces such as OLE which provides a software transport for importing data from one particular application, such as Excel~ into a second application, such as WordTM. Since the same service may be employed by various functions and CA 0223~838 1998-04-24 WO 97/19403 PCT~US96/18201 subroutines, the generation of a simple service error message is not terribly useful since it does not uniquely identify which branch of the application was involved.
Accordingly, a need exists to track and report errors with greater detail than that currently available.
Brref Descrzption of the Present lnventwn The present invention anticipates the rewrite of existing applications, or the gellel~,Lion of new applications lltili7in~ progr~mming languages that permit the generation and relaying of detailed error mf~cc~ges (heieillafLer referred to as"exceptions") that identifies a line of source code where the error is generated, as well as the path traversed by the exception on a return of the resulting error message to a user's display.
This is accomplished by generating a m~sc~ge, upon the occurrence of an exception, the message being populated with fields that define where the error occurred. This message is then relayed through subsequent application functions as part of a return path to the main program and subsequently to the user's display.
Once an error mess~ge is generated at one particular function layer, each subsequent functional layer affected generates its own m~sc~ge identifying the location of that subsequent function layer. The end result will be a stacking of these error mes.c~es, relating to an exception detected along the return path to the main program.
In this manner, the return path is completely identified since path data has populated fields of respective error messages, created at each affected functional layer. Part of the information includes the line of source code affected when the error was detected.
This level of detail in error reporting is stored for troubleshooting. It is most helpful to detect whether the error occurred as a result of a "bug" in the program itself, or whether it was most probably introduced as a result of user error.
CA 0223~838 1998-04-24 Certainly, the generation of hierarchical error reporting is extremely useful during development of a software application.
Brief Description of the Figures The above-mentioned objects and advantages of the present invention will be more clearly understood when considered in conjunction with the accompanying drawings, in which:
Fig. 1 is an archit~ctllral block diagram of a generalized computer system platform.
Fig. 2 is a hierarchical flowchart of a program in~ ing the two principal 10 layers of application and underlying software layer, namely, services.
Fig. 3 is a basic block diagram of a client-server ellvho~ ent involving database management.
Fig. 4 is a flowchart inflic~ting a typical prior art exception (error) h~n~linp;
process between functions of an application.
Fig. S is a flowchart, similar to Fig. 4, but indicating a hierarchical exception h~ntlling, as employed in the present invention.
Fig. 6 is a layout of an exception message, indicating typical fields to be populated with detailed error message information, as employed in the present invention.
Fig. 7 is flowchart, similar to that of Fig. 2 but indicating additional hierarchical error reporting, as contributed by the present invention.
Fig. 8 is a flowchart of a sequence of normal operation of a program wliLL~n in a language such as C + + .
Fig. 9 is a flowchart similar to Fig. 8, with operation of error h~ntlling 25 depicted.
CA 0223~838 l998-04-24 W O 97/19403 PCT~US96/18201 Detailed Descript~on Of The Invent~ion Fig. 1 is a generalized architecture of a personal co~ uL~l (PC). A user 10 relies upon a software program or application 12 to process data (for example, in a word processing program such as WordTM by Microscoft). The PC system is 5 controlled by an operating system 16, such as DOS~, Windows~, etc. The hardware of the col~uL~I 18 carries out the various processes required by the application and the operating system. Often times, an additional layer, indicated as services 14, interfaces with the application. For example, if data from the coll,~uLel software Excel~, by Microscoft, is to be inserted into a document being prepared in Word~, 10 an underlying service, such as the conventional service OLE may be required. Any of the boxes shown in Fig. 1 may generate an error. The purpose of the present invention is to report back, with detailed particularity to the user 10, an error report that identifies the path of the error as well as the line of source code where the error was encountered. R~ir~lly, in order to achieve this function, and as will be 15 explained hereinafter in greater detail, this requires the generation of an error message in the layer where the error is introduced. Subsequently "touched" levels in the return path of the error, to the user, generate a separate error mes~ge identifying each respective layer in the return path. The end result is a stacking of error messages that completely define the error and the return path of the error. The 2 o error messages created avoid the ambiguity that results from present error reporting systems where a similar error can occur in parallel branches so that a returned error does not fully identify the particular branch affected.
~ or example, in Fig. 2, the hierarchy for a prior art architectllre involving a software application and ~tten~1~nt services is depicted. More particularly, a main 25 program 20 controls subroutines 24 and 26. The main program also controls a function 22 which may be a simple comm~n-1 from the user 10, such as a retrieve file function, or similarly a read function of a ~l~t~ e record. As the hierarchy diagram of Fig. 2 indicates, the function 22 and subroutines 24, 26 may each cooperate with various services 28-35. As a reminder, "services" is used in the context of an CA 0223~838 l998-04-24 W O 97/19403 PCT~US96/18201 underlying software layer such as the case of OLE, as previously explained in connection with Fig. 1. Function 22 again refers to an application comm~n~l, such as retrieve a file or read a ~1~t~b~e record. Typically, software applications include a library of functions, any of which may be the particular function indicated by block 5 22 in Fig. 2.
In order to understand the limit~tions of the prior art reporting systems, consider more than one of the services 28-35 as generating an error message. Theerror message is reported back through a respective preceding level (function 22, subroutines 24, 26) to the main program 20. The user is informed as to the error~
0 which is typically a code or short phrase. However, since multiple branches from the main program invoke the same service, it would be impossible to determine through which path the error mçss~ge was returned.
The present invention solves this problem by keeping track of the path through which an error message is "rolled up" to a top level, namely the main program. The 5 error message, as will be developed hereinafter, not only develops informationconcerning the path through which the function error is returned, but also in-lir~tes which line of source code was being operated upon by the main program during thegeneration of the error. Such a reporting system is of great advantage during operation of the system, so that it may be determined whether a user is introducing the error, or whether a software problem exists. Usefulness in ~ietecting the latter mentioned problem is of particular importance during the debugging of applications during development.
In order to accomplish the objectives of the present invention, an application must be written (or an existing application rewritten) in a progr~mmin~ language that provides a tool kit sufficiently extensive to allow the types of error message generation presently required. Thus, in a preferred embodiment of the present invention, the known pro~ nl .lil~~ language C + + is employed.
CA 0223~838 1998-04-24 WO 97/lg403 PCTnJS96tl8201 To further explore the usefulness of the present invention, ler~lellce is made to Fig. 3 which shows a typical client-server environment for ~l~t~bz~e applications 40, 42 and 44. Typically, a user 36 monitors a display, which may be a graphicaluser interface (GUI) 38 (e.g., Windows~. This represents a data presentation layer for the user. The client is provided with a local ti~t~h~e 46 which is constantly refreshed during system operation. Col"~ ic~tion between the client and server occurs at a co~ lullication interface including a me~.c~in~ layer 48 at the client and a corresponding mess~in~ layer 50 at the server. The main rl~t~h~e 52 at the server is the source of the complete database. In typical applications, m~c.~ging may occur o by llfili7ing TCPIIP protocol.
In the system of Fig. 3, the user requests records from the main datahase 52.
During such an operation, if an error mess~ge were created, the local (1~t~ce 46would return a message in~ir~ting that the record could not be found. However, there would be no information as to which aspect of the coll~llunication chain actually caused the error. The pro~ ll",-i,-g language C~ + includes exception h~n-lling capabilities (error me~ges) and by virtue of the present invention, the language's exception h~n~llin~ is augmented, in a manner heretofore unknown, so as to add error path tracking. Thus, in the example discussed in connection with Fig. 3, the presentation layer 38 would enable the user to specifically track where in the c-~".~ iC~ion chain the error occurred, and which application was involved, including source code line identification.
Fig. 8 represents the normal flow of control from function to function in a program Wl iLIen in C + +, when there are no errors . In the Figure, Function A calls Function B. This results in a transfer of control to the beginning of Function B. At some time in its proces~ing, Function B calls Function C, resulting in a transfer of control to the beginnin~. of Function C. Function C calls no additional function and executes from beginning to end. When Function C has completed execution, controlis transferred back to Function B, which continues exec~ltin~, starting at the CA 0223~838 1998-04-24 instruction following the call to Function C. Function B then completes execlltin~
and returns control back to Function A. Function A resumes execution starting at t_e instruction following the call to Function B. Function A then completes executing and returns control to its caller (which could possibly be the operating system if 5 Function A is the "main" or topmost function in the application). Even though each function has "exception h~n-lling code", the code is never invoked since no error occurred.
Fig. 9 represents the same application as the previous Fig., except that, in this case, Function C detects an error during its proces~ing. When Function C "throws"
0 an exception, control transfers to Function B. In this case, however, instead of execution resuming in Function B at the instruction following the call to Function C, execution now transfers to the exception h~nrlling code that is part of Function B.
If this code passes the exception back up the chain ("rc~uow~i" the exception), then control transfers to the exception h~n~llin3~ code t_at is part of Function A.
Thus it is seen t'nat, typically, function execution does not occur sequentiallyin the sense that Function A completes processing followed by Function B, followed by Function C. Instead, Function A hlt~ll u~ts itself to call Function B, which in turn inlell u~ts itself to call Function C. When the lowest called function is complete, the next lowest function is then re-entered and allowed to complete. And so it goes, up 2 o and down the chain of function calls.
A further exploration of normal exception h~nrlling by C+ + is inrlic~te-l in Fig. 4, which does not include t'ne augmentation of the present invention. ~n Fig. 4, a portion of an application is indicated, employing C+ +, wherein four sequential Functions A-D (56-62) are shown. For example, if an exception 64 was "thrown"
25 (reported) by Function D, that exception is "caught" (received) by the previous layer C. As int1ir~cl in Fig. 4, tne exception is "rolled up" through prior Functions (A-C) (66, 68), thereby completing an error reporting process. However, although CA 0223~838 1998-04-24 the nature of the error may be identified, its particular path from Function D-A will not be derived.
Fig. ~ indicates the st~rking of exceptions so that the entire return path of anexception may be recorded. In accordance with the present invention, if Function D
throws Exception 1 (at lerelellce numeral 70), a message will be generated int1ic~ting that Function D is found to be in error and what line of source code was effected.
This message corresponds to Exception 1 (lerelellce numeral 70). The thrown Exception 1 is caught by Function C which generates its own message acknowledging the previous mes~ge. Thus, Exception 2, thrown by Function C (72), repeats the o information that Function D was found to be in error and that Function D was called from Punction C. Further, the line of source code, where the error occurred, is repeated.
Reference numeral 74 in Fig. S in~ tes the contimle-l rolling up of ~.xceptions 1 and 2 to the prece~ling Function B. Again, the error messages are stacked, with the Function B adding its own error message to repeat the previousinformation and adding the inforrnation that Function B called Function C.
Fig. 6 indicates the stacking of two exception (error) messages 76 and 78.
Block 76 indicates the typical types of fields that would be included in an exception generated by C+ + . These would typically include a text message, corresponding to the error. The file name indicates the original source file cont~ining the function generated error. The function or function module name is next included. The linenumber in the original source code is similarly listed. If an error code is generated from the applicat;on itself, for example error codes in a word processing or ~l~t~b~e program, the error code would be included, as well. A field is also available for explanatory information relative to the error (variable string information). Another field may include an alternate error code, which, for example, may be a programmer's own error code.
CA 0223~838 1998-04-24 3 PCTAJS96/~8201 In operation of the present invention, Fig. 7 indicates a software flow diagram with enhanced error reporting, as compared with the prior art of Fig. 2.
Thus, as shown in Fig. 7, if an error is ~letecte-l at step 80, between the mainprogram 20 and the function/sul~l~3uLille steps 22/24, 26 an exception is generated and 5 an error message 82 is populated, with the information in~ te~l in Fig. 6.
If no error occurs, the application continues with the appropriate function or subroutine. If an error is ~etecte~l during function 22, the error step 84 will populate an error message 90, and this is rolled up toward the main program by st~-king asecond error message 82 for completing the roll up path information. Similarly, if 0 errors occur during subroutines 24, 26, corresponding error steps 86 and 88 will populate an error me,cs~ge 90. In the example illustrated in Fig. 7, if no errormessages occur at the conclusion of the function or subroutines, various services 28-35 will occur.
An error during the first executed service will cause completion of a 5 corresponding error step 92-102, thereby causing the population of an error message 104 at this level. As in-lir.~t~f~ in Fig. 7, an error message 104 will be stacked with error mec~ges 90 and 82 during roll up of the error m~ss~ge to the main program 20. If no error occurs, the application may be returned to the main program 106.The end result of error reporting is the stacking of error messages to complete the information concerning return path and source code line number.
Therefore, by virtue of the present invention, software applications may be written (or lcw~ ell) in a progr~mming language such as C + + with enhanced error reporting as compared with the prior art. Full information concerning error path and source line identific~tion expedites error detection and correction in software that is being developed or thereafter.
It should be understood that the invention is not limite-l to the exact details of construction shown and described herein for obvious modifications will occur to persons skilled in the art.
Claims (7)
1. An error reporting system for computer applications, comprising:
means for detecting an error at a present step during the execution of a software application;
means for populating the fields of a first error message corresponding to the detected error, with comprehensive information identifying the error and the step where it occurred;
the message including a field identifying the line of source code being executedwhen the error occurred;
the error message being rolled up to a preceding step of the application;
means for populating a second error message with preselected path information regarding the preceding step and stacking the second error message to the first message;
means for rolling up the first and second error messages to earlier executed steps of the application and correspondingly populating respective error messages for stacking with the first and second messages, and means for displaying information from resulting stacked messages, to a user, thereby defining the path of the error and the line of source code executed when the error occurred.
means for detecting an error at a present step during the execution of a software application;
means for populating the fields of a first error message corresponding to the detected error, with comprehensive information identifying the error and the step where it occurred;
the message including a field identifying the line of source code being executedwhen the error occurred;
the error message being rolled up to a preceding step of the application;
means for populating a second error message with preselected path information regarding the preceding step and stacking the second error message to the first message;
means for rolling up the first and second error messages to earlier executed steps of the application and correspondingly populating respective error messages for stacking with the first and second messages, and means for displaying information from resulting stacked messages, to a user, thereby defining the path of the error and the line of source code executed when the error occurred.
2. The system set forth in claim 1 further including client-server components, comprising:
a client local database accessed by at least one application;
first means for messaging data requests from an application, located at the client, to the server;
second messaging means, located at the server, for communicating with the first messaging means; and a main database, located at the server, for downloading the data requested during an application via the first and second messaging means.
a client local database accessed by at least one application;
first means for messaging data requests from an application, located at the client, to the server;
second messaging means, located at the server, for communicating with the first messaging means; and a main database, located at the server, for downloading the data requested during an application via the first and second messaging means.
3. In a data processing system having a software application invoking at least one layer of software services, an error reporting apparatus comprising:
means for (detecting an error at a present step during the execution of a service invoked by the software application;
means for populating the fields of a first error message corresponding to the detected error in execution of the service, with comprehensive information identifying the error and the step where it occurred;
the message including a field identifying the line of source code being executedwhen the error occurred;
the error message being rolled up to a preceding step of the application;
means for populating a second error message with preselected path information regarding the preceding step and stacking the second error message to the first message;
means for rolling up the first and second error messages to earlier executed steps of the application and correspondingly populating respective error messages for stacking with the first and second messages; and means for displaying resulting stacked messages to a user thereby defining the path of the error occurring during execution of the service and the line of source code executed when the error occurred.
means for (detecting an error at a present step during the execution of a service invoked by the software application;
means for populating the fields of a first error message corresponding to the detected error in execution of the service, with comprehensive information identifying the error and the step where it occurred;
the message including a field identifying the line of source code being executedwhen the error occurred;
the error message being rolled up to a preceding step of the application;
means for populating a second error message with preselected path information regarding the preceding step and stacking the second error message to the first message;
means for rolling up the first and second error messages to earlier executed steps of the application and correspondingly populating respective error messages for stacking with the first and second messages; and means for displaying resulting stacked messages to a user thereby defining the path of the error occurring during execution of the service and the line of source code executed when the error occurred.
4. The system set forth in claim 3 further including client-server components, comprising:
a client local database accessed by at least one application;
first means for messaging data requests from an application, located at the client, to the server;
second messaging means, located at the server, for communicating with the first messaging means; and a main database, located at the server, for downloading the data requested during an application via the first and second messaging means.
a client local database accessed by at least one application;
first means for messaging data requests from an application, located at the client, to the server;
second messaging means, located at the server, for communicating with the first messaging means; and a main database, located at the server, for downloading the data requested during an application via the first and second messaging means.
5. A method for reporting errors to a user during execution of a software application, the method including the steps of:
detecting an error at a present step during the execution of a software application;
populating the fields of a first error message corresponding to the detected error, with comprehensive information identifying the error and the step where it occurred;
the message including a field identifying the line of source code being executedwhen the error occurred;
the error message being rolled up to a preceding step of the application;
populating a second error message with preselected path information regarding the preceding step and stacking the second error message to the first message;
rolling up the first and second error messages to earlier executed steps of the application and correspondingly populating respective error messages for stacking with the first and second messages; and displaying information from resulting stacked messages, to a user, thereby defining the path of the error and the line of source code executed when the error occurred.
detecting an error at a present step during the execution of a software application;
populating the fields of a first error message corresponding to the detected error, with comprehensive information identifying the error and the step where it occurred;
the message including a field identifying the line of source code being executedwhen the error occurred;
the error message being rolled up to a preceding step of the application;
populating a second error message with preselected path information regarding the preceding step and stacking the second error message to the first message;
rolling up the first and second error messages to earlier executed steps of the application and correspondingly populating respective error messages for stacking with the first and second messages; and displaying information from resulting stacked messages, to a user, thereby defining the path of the error and the line of source code executed when the error occurred.
6. The method set forth in claim 5 further including client-server communicationsteps comprising:
accessing a client local database, by at least one application;
messaging data requests, by the client to the server;
downloading the data requested during an application, from a server based main database, via return messaging, to the local database at the client.
accessing a client local database, by at least one application;
messaging data requests, by the client to the server;
downloading the data requested during an application, from a server based main database, via return messaging, to the local database at the client.
7. In a data processing system having a software application invoking at least one layer of software services, an error reporting method comprising the steps:
detecting an error at a present step during the execution of a service invoked by the software application;
populating the fields of a first error message corresponding to the detected error, in execution of the service, with comprehensive information identifying the error and the step where it occurred;
the message including a field identifying the line of source code being executedwhen the error occurred;
the error message being rolled up to a preceding step of the application;
populating a second error message with preselected path information regarding the preceding step and stacking the second error message to the first message;
rolling up the first and second error messages to earlier executed steps of the application and correspondingly populating respective error messages for stacking with the first and second messages; and displaying information from resulting stacked messages, to a user, thereby defining the path of the error occurring during the execution of the service and the line of source code executed when the error occurred.
The method set forth in claim 7 further including client-server communication steps comprising;
accessing a client local database,by at least one application;
messaging data requests,by the client to the server;
downloading the data requested during an application, from a server based main database, via return messaging, to the local database at the client.
detecting an error at a present step during the execution of a service invoked by the software application;
populating the fields of a first error message corresponding to the detected error, in execution of the service, with comprehensive information identifying the error and the step where it occurred;
the message including a field identifying the line of source code being executedwhen the error occurred;
the error message being rolled up to a preceding step of the application;
populating a second error message with preselected path information regarding the preceding step and stacking the second error message to the first message;
rolling up the first and second error messages to earlier executed steps of the application and correspondingly populating respective error messages for stacking with the first and second messages; and displaying information from resulting stacked messages, to a user, thereby defining the path of the error occurring during the execution of the service and the line of source code executed when the error occurred.
The method set forth in claim 7 further including client-server communication steps comprising;
accessing a client local database,by at least one application;
messaging data requests,by the client to the server;
downloading the data requested during an application, from a server based main database, via return messaging, to the local database at the client.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US08/560,426 US5974568A (en) | 1995-11-17 | 1995-11-17 | Hierarchical error reporting system |
| US08/560,426 | 1995-11-17 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2235838A1 true CA2235838A1 (en) | 1997-05-29 |
Family
ID=24237778
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002235838A Abandoned CA2235838A1 (en) | 1995-11-17 | 1996-11-15 | Hierarchical error reporting system |
Country Status (5)
| Country | Link |
|---|---|
| US (1) | US5974568A (en) |
| EP (1) | EP0861466A1 (en) |
| JP (1) | JP2001511918A (en) |
| CA (1) | CA2235838A1 (en) |
| WO (1) | WO1997019403A1 (en) |
Families Citing this family (78)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6421740B1 (en) * | 1995-12-27 | 2002-07-16 | Apple Computer, Inc. | Dynamic error lookup handler hierarchy |
| US6138253A (en) * | 1997-05-29 | 2000-10-24 | Oracle Corporation | Method and apparatus for reporting errors in a computer system |
| US6269460B1 (en) * | 1998-09-01 | 2001-07-31 | International Business Machines Corporation | Dynamic enhancement of error condition handling and displayed error messages in computer operations |
| US6438716B1 (en) * | 1998-10-22 | 2002-08-20 | International Business Machines Corporation | Composition of error messages in an error message system based upon non-local contextual information |
| US6363503B1 (en) * | 1998-11-24 | 2002-03-26 | Autodesk, Inc. | Error handling and representation in a computer-aided design environment |
| US6532552B1 (en) * | 1999-09-09 | 2003-03-11 | International Business Machines Corporation | Method and system for performing problem determination procedures in hierarchically organized computer systems |
| US6763497B1 (en) * | 2000-04-26 | 2004-07-13 | Microsoft Corporation | Method and apparatus for displaying computer program errors as hypertext |
| US6857085B1 (en) * | 2000-05-15 | 2005-02-15 | Microsoft Corporation | Method and system for handling an unexpected exception generated by an application |
| US6629267B1 (en) * | 2000-05-15 | 2003-09-30 | Microsoft Corporation | Method and system for reporting a program failure |
| SE518104C2 (en) * | 2000-06-13 | 2002-08-27 | Saab Ab | Software maintenance system and method |
| US7100082B2 (en) * | 2000-08-04 | 2006-08-29 | Sun Microsystems, Inc. | Check creation and maintenance for product knowledge management |
| US7475293B1 (en) | 2000-08-04 | 2009-01-06 | Sun Microsystems, Inc. | Product check matrix |
| US7146535B2 (en) * | 2000-08-04 | 2006-12-05 | Sun Microsystems, Inc. | Product knowledge management |
| US6678639B2 (en) * | 2000-08-04 | 2004-01-13 | Sun Microsystems, Inc. | Automated problem identification system |
| US7051243B2 (en) * | 2002-04-30 | 2006-05-23 | Sun Microsystems, Inc. | Rules-based configuration problem detection |
| US7100083B2 (en) * | 2000-08-04 | 2006-08-29 | Sun Microsystems, Inc. | Checks for product knowledge management |
| US7146536B2 (en) * | 2000-08-04 | 2006-12-05 | Sun Microsystems, Inc. | Fact collection for product knowledge management |
| JP2003114813A (en) * | 2001-10-03 | 2003-04-18 | Ibm Japan Ltd | Analysis server, program analysis network system and program analysis method |
| US7305548B2 (en) | 2001-10-22 | 2007-12-04 | Microsoft Corporation | Using atomic messaging to increase the security of transferring data across a network |
| US7036052B2 (en) * | 2001-10-22 | 2006-04-25 | Microsoft Corporation | Remote error detection by preserving errors generated throughout a software stack within a message |
| US7447624B2 (en) * | 2001-11-27 | 2008-11-04 | Sun Microsystems, Inc. | Generation of localized software applications |
| US7120833B2 (en) * | 2002-04-26 | 2006-10-10 | Alcatel | Error codes in Agent X |
| US7240247B2 (en) * | 2002-04-29 | 2007-07-03 | Intel Corporation | Providing a chain of tokenized error and state information for a call stack |
| US6983401B2 (en) * | 2002-05-01 | 2006-01-03 | Bellsouth Intellectual Property Corporation | System and method for generating a chronic circuit report for use in proactive maintenance of a communication network |
| US20040078724A1 (en) * | 2002-06-26 | 2004-04-22 | Keller S. Brandon | Event processing system |
| CA2393196C (en) * | 2002-07-11 | 2005-10-04 | Corel Corporation | System and method for preflighting documents |
| GB2395578A (en) * | 2002-11-22 | 2004-05-26 | Ibm | Fault tracing in systems with virtualization layers |
| JP2004227080A (en) * | 2003-01-20 | 2004-08-12 | Nec Corp | Information processing system, mobile terminal, and information processing server |
| US20060202186A1 (en) * | 2003-01-21 | 2006-09-14 | On The Fence Technologies, Llc. Corporation | Methods and apparatus for fencing and other outdoor structures |
| US8032792B2 (en) * | 2003-07-11 | 2011-10-04 | Avicode, Inc. | Dynamic discovery algorithm |
| US20060031432A1 (en) * | 2004-05-21 | 2006-02-09 | Bea Systens, Inc. | Service oriented architecture with message processing pipelines |
| US20050273847A1 (en) * | 2004-05-21 | 2005-12-08 | Bea Systems, Inc. | Programmable message processing stage for a service oriented architecture |
| US20050273517A1 (en) * | 2004-05-21 | 2005-12-08 | Bea Systems, Inc. | Service oriented architecture with credential management |
| US7774485B2 (en) * | 2004-05-21 | 2010-08-10 | Bea Systems, Inc. | Dynamic service composition and orchestration |
| US20060007918A1 (en) * | 2004-05-21 | 2006-01-12 | Bea Systems, Inc. | Scaleable service oriented architecture |
| US20050267947A1 (en) * | 2004-05-21 | 2005-12-01 | Bea Systems, Inc. | Service oriented architecture with message processing pipelines |
| US20060031433A1 (en) * | 2004-05-21 | 2006-02-09 | Bea Systems, Inc. | Batch updating for a service oriented architecture |
| US20050264581A1 (en) * | 2004-05-21 | 2005-12-01 | Bea Systems, Inc. | Dynamic program modification |
| US20050273502A1 (en) * | 2004-05-21 | 2005-12-08 | Patrick Paul B | Service oriented architecture with message processing stages |
| US20050273520A1 (en) * | 2004-05-21 | 2005-12-08 | Bea Systems, Inc. | Service oriented architecture with file transport protocol |
| US20060031353A1 (en) * | 2004-05-21 | 2006-02-09 | Bea Systems, Inc. | Dynamic publishing in a service oriented architecture |
| US20050270970A1 (en) * | 2004-05-21 | 2005-12-08 | Bea Systems, Inc. | Failsafe service oriented architecture |
| US20050273516A1 (en) * | 2004-05-21 | 2005-12-08 | Bea Systems, Inc. | Dynamic routing in a service oriented architecture |
| US20050267892A1 (en) * | 2004-05-21 | 2005-12-01 | Patrick Paul B | Service proxy definition |
| US20060031431A1 (en) * | 2004-05-21 | 2006-02-09 | Bea Systems, Inc. | Reliable updating for a service oriented architecture |
| US20060031354A1 (en) * | 2004-05-21 | 2006-02-09 | Bea Systems, Inc. | Service oriented architecture |
| US7653008B2 (en) * | 2004-05-21 | 2010-01-26 | Bea Systems, Inc. | Dynamically configurable service oriented architecture |
| US20050273497A1 (en) * | 2004-05-21 | 2005-12-08 | Bea Systems, Inc. | Service oriented architecture with electronic mail transport protocol |
| US20050278374A1 (en) * | 2004-05-21 | 2005-12-15 | Bea Systems, Inc. | Dynamic program modification |
| US7310684B2 (en) * | 2004-05-21 | 2007-12-18 | Bea Systems, Inc. | Message processing in a service oriented architecture |
| US20050278335A1 (en) * | 2004-05-21 | 2005-12-15 | Bea Systems, Inc. | Service oriented architecture with alerts |
| US20060136555A1 (en) * | 2004-05-21 | 2006-06-22 | Bea Systems, Inc. | Secure service oriented architecture |
| US20050273521A1 (en) * | 2004-05-21 | 2005-12-08 | Bea Systems, Inc. | Dynamically configurable service oriented architecture |
| US20060069791A1 (en) * | 2004-05-21 | 2006-03-30 | Bea Systems, Inc. | Service oriented architecture with interchangeable transport protocols |
| US20060080419A1 (en) * | 2004-05-21 | 2006-04-13 | Bea Systems, Inc. | Reliable updating for a service oriented architecture |
| US20060031481A1 (en) * | 2004-05-21 | 2006-02-09 | Bea Systems, Inc. | Service oriented architecture with monitoring |
| US20060031930A1 (en) * | 2004-05-21 | 2006-02-09 | Bea Systems, Inc. | Dynamically configurable service oriented architecture |
| US20060031355A1 (en) * | 2004-05-21 | 2006-02-09 | Bea Systems, Inc. | Programmable service oriented architecture |
| US20060005063A1 (en) * | 2004-05-21 | 2006-01-05 | Bea Systems, Inc. | Error handling for a service oriented architecture |
| US8539003B2 (en) * | 2005-04-22 | 2013-09-17 | Sap Ag | Systems and methods for identifying problems of a business application in a customer support system |
| US20060242194A1 (en) * | 2005-04-22 | 2006-10-26 | Igor Tsyganskiy | Systems and methods for modeling and manipulating a table-driven business application in an object-oriented environment |
| US7720879B2 (en) * | 2005-04-22 | 2010-05-18 | Sap Ag | Methods of using an integrated development environment to configure business applications |
| US7702638B2 (en) * | 2005-04-22 | 2010-04-20 | Sap Ag | Systems and methods for off-line modeling a business application |
| US7958486B2 (en) | 2005-04-22 | 2011-06-07 | Sap Ag | Methods and systems for data-focused debugging and tracing capabilities |
| US20060242197A1 (en) * | 2005-04-22 | 2006-10-26 | Igor Tsyganskiy | Methods of transforming application layer structure as objects |
| US20060293935A1 (en) * | 2005-04-22 | 2006-12-28 | Igor Tsyganskiy | Methods and systems for incrementally exposing business application errors using an integrated display |
| US20060293934A1 (en) * | 2005-04-22 | 2006-12-28 | Igor Tsyganskiy | Methods and systems for providing an integrated business application configuration environment |
| US8984636B2 (en) | 2005-07-29 | 2015-03-17 | Bit9, Inc. | Content extractor and analysis system |
| US20070027999A1 (en) * | 2005-07-29 | 2007-02-01 | Allen James P | Method for coordinated error tracking and reporting in distributed storage systems |
| US8272058B2 (en) | 2005-07-29 | 2012-09-18 | Bit 9, Inc. | Centralized timed analysis in a network security system |
| US7895651B2 (en) | 2005-07-29 | 2011-02-22 | Bit 9, Inc. | Content tracking in a network security system |
| US7707559B2 (en) * | 2005-08-30 | 2010-04-27 | International Business Machines Corporation | Analysis of errors within computer code |
| US8996394B2 (en) | 2007-05-18 | 2015-03-31 | Oracle International Corporation | System and method for enabling decision activities in a process management and design environment |
| US8185916B2 (en) | 2007-06-28 | 2012-05-22 | Oracle International Corporation | System and method for integrating a business process management system with an enterprise service bus |
| US9229738B2 (en) * | 2009-06-19 | 2016-01-05 | International Business Machines Corporation | Software development tool for providing user context information to improve message quality at development time |
| DE102009030774B4 (en) * | 2009-06-27 | 2020-01-30 | Bayerische Motoren Werke Aktiengesellschaft | Process for computer-aided detection of errors during the execution of one or more software-based programs in a system of components |
| US8245081B2 (en) * | 2010-02-10 | 2012-08-14 | Vmware, Inc. | Error reporting through observation correlation |
| WO2012138983A1 (en) * | 2011-04-07 | 2012-10-11 | Siemens Healthcare Diagnostics Inc. | Methods for hierarchically identifying root cause errors |
Family Cites Families (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4481577A (en) * | 1982-03-25 | 1984-11-06 | At&T Bell Laboratories | Method of operating a computer system to provide customized responses |
| US4679195A (en) * | 1985-04-10 | 1987-07-07 | Amdahl Corporation | Error tracking apparatus in a data processing system |
| US5047977A (en) * | 1988-04-08 | 1991-09-10 | International Business Machines Corporation | Methods of generating and retrieving error and task message records within a multitasking computer system |
| DE69228986T2 (en) * | 1991-02-05 | 1999-08-12 | Storage Technology Corp | MAINTENANCE DEVICE AND METHODS TRIGGERED BY KNOWLEDGE-BASED KNOWLEDGE-BASED MACHINE |
| US5432795A (en) * | 1991-03-07 | 1995-07-11 | Digital Equipment Corporation | System for reporting errors of a translated program and using a boundry instruction bitmap to determine the corresponding instruction address in a source program |
| US5598560A (en) * | 1991-03-07 | 1997-01-28 | Digital Equipment Corporation | Tracking condition codes in translation code for different machine architectures |
| US5450575A (en) * | 1991-03-07 | 1995-09-12 | Digital Equipment Corporation | Use of stack depth to identify machine code mistakes |
| US5383201A (en) * | 1991-12-23 | 1995-01-17 | Amdahl Corporation | Method and apparatus for locating source of error in high-speed synchronous systems |
| JPH07225707A (en) * | 1994-02-10 | 1995-08-22 | Fujitsu Ltd | Test method for application and test supporting device for the same |
| US5712972A (en) * | 1995-06-07 | 1998-01-27 | Sony Corporation | Identification of faults in data paths and functional units of a central processing unit by a systematic execution of test instructions |
| KR0142955B1 (en) * | 1995-06-17 | 1998-08-01 | 김광호 | Cordless calling method without a near-far problem |
-
1995
- 1995-11-17 US US08/560,426 patent/US5974568A/en not_active Expired - Lifetime
-
1996
- 1996-11-15 CA CA002235838A patent/CA2235838A1/en not_active Abandoned
- 1996-11-15 WO PCT/US1996/018201 patent/WO1997019403A1/en not_active Application Discontinuation
- 1996-11-15 EP EP96941346A patent/EP0861466A1/en not_active Withdrawn
- 1996-11-15 JP JP51978697A patent/JP2001511918A/en active Pending
Also Published As
| Publication number | Publication date |
|---|---|
| EP0861466A1 (en) | 1998-09-02 |
| WO1997019403A1 (en) | 1997-05-29 |
| JP2001511918A (en) | 2001-08-14 |
| US5974568A (en) | 1999-10-26 |
| MX9803877A (en) | 1998-10-31 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2235838A1 (en) | Hierarchical error reporting system | |
| US6308224B1 (en) | Method of generating an implementation of a workflow process model in an object environment | |
| US6785882B1 (en) | Process-driven tool interface for an object management system | |
| US6269460B1 (en) | Dynamic enhancement of error condition handling and displayed error messages in computer operations | |
| US7454399B2 (en) | Application integration system and method using intelligent agents for integrating information access over extended networks | |
| US5339430A (en) | System for dynamic run-time binding of software modules in a computer system | |
| US5307498A (en) | Automated method for adding hooks to software | |
| US6151700A (en) | Object oriented distributed programming system for computer controlled networks with selective capture of program property data identifying a particular program version | |
| US7870537B2 (en) | System and method for real-time applications modification | |
| US6973643B2 (en) | Method, system and program for handling errors occurring in function calls | |
| US5758348A (en) | Method for generically manipulating properties of objects in an object oriented repository | |
| US6049807A (en) | Technique for maintaining object integrity during modification of a persistent store of objects | |
| US20040123271A1 (en) | Remote debugging through firewalls | |
| US20080201358A1 (en) | Data Processing For Objects With Unknown Data Structures | |
| US6892202B2 (en) | Optimistic transaction compiler | |
| KR20010022215A (en) | System and method for generating year 2000 test cases | |
| US6484310B1 (en) | Patterns for modeling computer component interactions | |
| US5870727A (en) | Rule-based system for the provision of complex navigational logic | |
| US6327629B1 (en) | Stored procedure universal calling interface | |
| US6035301A (en) | Method and apparatus for accessing transaction services using object linking and embedding | |
| US7574625B2 (en) | Active content wizard testing | |
| AU2017276243B2 (en) | System And Method For Generating Service Operation Implementation | |
| US20020072928A1 (en) | Method and system for managing component changes to a business critical application in a production environment | |
| JPH09171473A (en) | Method for management of error and data-processing system | |
| Cagnin et al. | Reengineering using design patterns |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| FZDE | Discontinued |