Electrical computers and digital processing systems: processing – Processing control – Branching
Reexamination Certificate
1998-09-29
2001-09-11
Niebling, John F. (Department: 2812)
Electrical computers and digital processing systems: processing
Processing control
Branching
C712S242000
Reexamination Certificate
active
06289446
ABSTRACT:
COPYRIGHT NOTICE
A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
BACKGROUND OF THE INVENTION
Field of the Invention
The present invention relates generally to systems and methods for increasing the reliability and improving the behavior of software programs. More particularly, the present invention relates to exception-handling systems and methods which assist software developers in the task of ensuring that programs operative on digital computers can recover from exceptional conditions and runtime program errors.
Before a digital computer may accomplish a desired task, it must receive an appropriate set of instructions. Executed by the computer's microprocessor, these instructions, collectively referred to as a “computer program,” direct the operation of the computer.
Computers essentially only understand “machine code,” that is, the low-level instructions for performing specific tasks interpreted as specific instructions by the computer's microprocessor. Since machine language or machine code is the only language computers actually understand, all other programming languages represent ways of structuring “human” language so that humans can get computers to perform specific tasks.
While it is possible for humans to compose meaningful programs in machine code, practically all software development today employs one or more of the available programming languages. The most widely-used programming languages are the “high-level” languages, such as C++/C or Pascal.
A program called a “compiler” translates these instructions into the requisite machine language. In the context of this translation, the program written in the high-level language is called the “source code” or source program. The ultimate output of the compiler is an “object module,” which includes instructions for execution by a target processor. Although an object module includes code for instructing the operation of a computer, the object module itself is not in a form which may be directly executed by a computer. Instead, it must undergo a “linking” operation before the final executable program is created.
Linking may be thought of as the general process of combining or linking together one or more compiled object modules to create an executable program. This task usually falls to a program called a “linker.” In typical operation, a linker receives, either from the user or from an integrated compiler, a list of object modules desired to be included in the link operation. The linker scans the object modules from the object and library files specified. After resolving interconnecting references as needed, the linker constructs an executable image by organizing the object code from the modules of the program in a format understood by the operating system program loader. The end result of linking is executable code (typically an .exe file) which, after testing and quality assurance, is passed to the user with appropriate installation and usage instructions, or to a factory for installation in products with embedded computer systems.
Development of programs is largely a trial and error process. Errors that emerge from this program development cycle can be divided into broad classes, including compile-time errors, linkage errors, runtime errors, and errors arising at runtime due to unexpected failures beyond programmer control. Examples of such unexpected failures include failures at external resources shared via a network, and failure of the network. Proper development methodologies and quality controls will remove both compile-time errors (such as syntax and format violations) and linkage errors (such as library and global naming inconsistencies), but runtime errors are less amenable to systematic elimination. Indeed, the supreme importance of runtime errors stems from the fact that they are usually discovered by, and provide major frustration to, the end user. Unless handled properly, runtime errors simply abort (terminate) execution, leaving the system in a questionable state and the user uncertain as to what went wrong and what to do next. There are many reasons for the intractability of the runtime error problem. First, it is difficult to predict every user action during program execution. Although the conscientious programmer guides the user with helpful menus and prompts, and aims to insert code that checks the validity of each user response, in practice, it remains a major programming challenge to anticipate and respond to arbitrary user input.
Second, it is difficult, and often impossible, to predict the availability of the diverse hardware and software resources required as program execution unfolds. For instance, the running program might request RAM (random access memory) and disk storage allocations at diverse points of its execution, in the absence of which the program cannot usefully continue. Similarly, the running program might call operating system, library, or other toutines that are, for various reasons beyond the programmer's control, unavailable at that moment. A common error, for instance, occurs when a program seeks access to a file that is not available due to a network failure, for example. As with hardware resource exceptions, the program must either take evasive action or simply terminate (exit or abort). Exceptions of this type are especially common in modem computing environments where a set of independent user applications, or a set of independently executing threads within the same program, must share the same resources.
Apart from resource availability and unpredicted user actions, a further source of runtime errors involves genuine coding bugs not detectable during compilation or linkage. For example, an arithmetical expression, accepted as legal by the compiler, may produce a runtime error for certain values of its variable components. Typical cases are the “divide-by-zero” error and similar situations where the expression cannot be correctly evaluated. Such errors are predictable and avoidable in theory. In practice, however, traditional exception-handling solutions have involved a hard-coded plethora of conditional tests of variable values before each expression is evaluated, followed by ad hoc routines to bypass invalid evaluations. The approach is at best tedious and prone to error.
Most of the high-level languages currently used for program development exploit the concept of modularity whereby a commonly required set of operations can be encapsulated in a separately named subroutine, procedure, or function. Once coded, such subroutines can be reused by “calling” them from any point in the main program. Further, a subroutine may call a subroutine, and so on, so that in most cases an executing program is seldom a linear sequence of instructions. In the C language, for example, a main( ) program is written which calls a sequence of functions, each of which can call functions, and so on. If all goes well, control eventually returns to main( ). This nesting of function calls simplifies the construction of programs but, at the same time, complicates the handling of exceptions. The essence of a function call is that it must pass any arguments (or parameters) to the target function, transfer control to the memory section holding the function's executable code, return the result of the call, and at the same time, store sufficient information to ensure that subsequent execution resumes immediately after the point where the original function call was made. This function-calling mechanism, as is well-known in the art, is usually achieved by pushing and pulling data and memory addresses on and off a stack prior to, during, and after, the call. A stack is simply a dedicated portion of memory usually organized as a LIFO (last in, first out) data structure
Axis AB
Cary Charles C.
Cary & Kelly LLP
Niebling John F.
Whitmore Stacy
LandOfFree
Exception handling utilizing call instruction with context... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Exception handling utilizing call instruction with context..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Exception handling utilizing call instruction with context... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2487132