Error detection/correction and fault detection/recovery – Data processing system error or fault handling – Reliability and availability
Reexamination Certificate
2000-02-04
2004-03-30
Beausoliel, Robert (Department: 2785)
Error detection/correction and fault detection/recovery
Data processing system error or fault handling
Reliability and availability
C714S046000, C717S124000, C717S125000
Reexamination Certificate
active
06715109
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention.
The present invention relates to methods of debugging application programs that use the standard output and standard error streams. More particularly, the present invention is related to ways of capturing standard error information from an application program written in the Java programming language.
2. Present State of the Art.
Currently, most application program development is done in a high level programming language, such as C++ or Java, in an IDE. An IDE provides many debugging capabilities, such as stepping through the execution of a program while simultaneously observing the point of execution in source code. One such ability is to capture the standard error messages delivered through System.err (Java) or stderr © and C++). When errors are manifest through these standard streams, they are captured by the IDE and can be observed by the developer as an aid in debugging. Furthermore, when a program is started from system console, the information from the standard streams is available to a user at the system console.
There are situations that arise where the standard stream information can be lost to the user. The present invention is directed to providing a way to capture and make accessible to a user the information from the standard stream that would otherwise be lost.
One situation where standard streams information is lost occurs in GUI environment (outside the IDE) where error information may be lost from the standard streams since the streams are designed to output information into a character-based display mechanism such as a CRT display of a “dumb” terminal, a DOS prompt, on a UNIX shell interpreter, etc. In a GUI environment, applications are started or “launched” by selecting (e.g., operating a mouse so as to manipulate a cursor over the icon or menu item) an icon representative of the application and initiating the action (e.g., by “clicking” the mouse or hitting “enter”). Therefore, in the designated environment for application program deployment (e.g., the Windows desktop), there is no inherent mechanism for capturing the error message information for use by the user of the program and it becomes irretrievably lost.
It is desirable to have this information for debugging purposes, particularly when the application program is released from development in early field testing or in a product offering. If there are errors reported through the standard streams, they would be available to product support as additional (and highly useful) information used to resolve the problem.
This error information is especially relevant for Java programs as a “stack trace” API call can be invoked when an error occurs. The output of the “stack trace” API call is sent to System.err and gives the entire invocation stack of the application program at the time of error. This in turn is highly useful information since the location in the program execution at the time of the error can then be determined.
One way currently used to ameliorate this problem involves the use of a system console, such as a DOS prompt in Windows. The system console itself is first started, and within that console the name of the program may be specified on the character interface to launch the application program. The application program will start and run normally, however, any error information (or other information on the standard streams) will be presented on the system console.
While use of the system console as described above is acceptable in some circumstances, it is limited use in many practical situations. For example, some errors occur infrequently and having the added overhead of starting the program in a user console every time adds to the difficulty of resolving the problem. This is especially so when the application is deployed in the field. In other words, it would be better to have a console directly part of the actual application program.
Furthermore, depending on the internal organization of an application program, using the system console as described above will not work. For example, when the original application program spawns an independent process (i.e., one where the original process does not wait for the child to complete before continuing forward with processing), error messages and other information written to the standard streams is lost as to the independent processes because the system console will only receive error messages for the original process. It is relatively common in an application program of even medium complexity to have many different processes running independently.
Finally, there are yet other situations that may commonly arise where the information written to the standard streams may not be available to a user of an application program. What is needed is a convenient way to make standard stream information accessible to users for informational and debugging purposes in those situations where the information would otherwise be lost.
SUMMARY OF THE INVENTION
An object of the present invention is to provide an easy mechanism that allows error or other information placed onto a standard stream in a development environment (e.g., System.err or System.out in the Java development environment) accessible in situations when it would otherwise be lost.
Additional objects and advantages of the present invention will be realized from the following description that follows by those skilled in the art or may be learned by practicing the invention. The objects and advantages of the present invention may be obtained by the ways shown and as particularly pointed out in the appended claims.
To achieve the foregoing objects, and in accordance with the invention as embodied and broadly described herein, a method, computer program product, and system for making standard stream data accessible that would otherwise be lost in applications programs is provided.
Information placed on a standard stream, such as System.err or System.out in the Java development environment, can be lost during normal operation of the program (e.g., when not started from a system console or within an Integrated Development Environment (IDE)). A new stream is created and the standard stream is redirected to this new stream. Once data placed on the standard stream is available on the new stream it can be manipulated as desired and made available through a console or by placing the information into a file.
Essentially, the standard stream is “observed” or monitored by a group of observers, each implementing a common interface method that is called upon when any new data is written to the standard stream. The implementation of an observer may, for example, capture the data and display it on a console or write it into a log file for future reference.
In other words, information being carried by the standard stream is monitored or observed by attaching to the standard stream and listening for data carried thereon. It is then made available by capturing the data and displaying it on a console, putting it into a file for future reference, etc.
REFERENCES:
patent: 4792918 (1988-12-01), Hirase et al.
patent: 5438574 (1995-08-01), Taniguchi
patent: 5583988 (1996-12-01), Crank et al.
patent: 5673390 (1997-09-01), Mueller
patent: 5701487 (1997-12-01), Arbouzov
patent: 5845120 (1998-12-01), Reddy et al.
patent: 5881289 (1999-03-01), Duggan et al.
patent: 5892898 (1999-04-01), Fujii et al.
patent: 5905892 (1999-05-01), Nielsen et al.
patent: 5946488 (1999-08-01), Tanguay et al.
patent: 6094529 (2000-07-01), Jeffries et al.
patent: 6115544 (2000-09-01), Mueller
patent: 6128011 (2000-10-01), Peng
patent: 6411974 (2002-06-01), Graham et al.
Javac—Java programming language compiler, Sun Microsystems.*
Roedy Green, Java Glossary: javac.exe, Canadian Mind Products.*
JavaDepend, http://ptolemy.eecs.berkely.edu/~cxh/java/javadepend.*
Jonathan B. Rosenberg, How Debuggers Work, 1996, John Wiley & Sons Inc., pp. 77 and 188-189.*
G.D. Boldt, et al., “Blocking Modal Dialog Support for Java”, IBM Technical Disclosure Bulletin, vol. 40, No. 04, Apr. 1997. pp. 151
Charlet Kyle J.
Kim Greg S.
Beausoliel Robert
Duncan Marc
Fay Sharpe Fagan Minnich & McKee LLP
International Business Machines - Corporation
LandOfFree
Method, computer program product, and system for making... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method, computer program product, and system for making..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method, computer program product, and system for making... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3274912