In this paper, we analyse the exception handling mechanism of a state-of-the-art industrial embedded software system. Like many systems implemented in classic programming languages, our subject system uses the popular return-code idiom for dealing with exceptions. Our goal is to evaluate the fault-proneness of this idiom, and we therefore present a characterisation of the idiom, a fault model accompanied by an analysis tool, and empirical data. Our findings show that the idiom is indeed fault prone, but that a simple solution can lead to significant improvements. 1.

this article differentiate the exception-handling needs of CB-RTS as compared to other software paradigms and can serve as a driving force for future research into exception-handling technology.

This paper presents a general model for dealing with abnormal events during program execution and describes how this model is implemented in the System. (The System is a library of C definitions that provide light-weight concurrency on uniprocessor and multiprocessor computers running the UNIX operating system. ) Two different techniques can be used to deal with an abnormal event: an exception, which results in an exceptional change in control flow from the point of the abnormal event; and an intervention, which is a routine call from the point of the abnormal event that performs some corrective action. Users can define named exceptions and interventions in conjunction with ones defined by the System. Exception handlers and intervention routines for dealing with abnormal events can be defined/installed at any point in a program. An exception or intervention can then be raised or called, passing data about the abnormal event and returning results for interventions. Interventions can also be activated in other tasks, like a UNIX signal. Such asynchronous interventions may interrupt a task's execution and invoke the specified intervention routine. Asynchronous interventions are found to be useful to get another task's attention when it is not listening through the synchronous mechanism

Loops with multiple-exits and flags detract from the quality of imperative programs. They tend to make control-structures difficult to understand and, at the same time, introduce the risk of non-termination and other correctness problems. A systematic, generally applicable procedure, called loop rationalization, which removes such features and simplifies loop structures is presented. This method, which is founded on the principle of separation of concerns, is based on strongest postcondition calculations and congruent equivalence transformations. Not only does this method logically simplify loop structures; it also detects a range of defects including a class of non-termination problems and unreachable code. 1.

Loops with multiple-exits and flags detract from the quality of imperative programs. They tend to make control- structures difficult to understand and, at the same time, introduce the risk of non-termination and other correctness problems. A systematic, generally applicable procedure, called loop rationalization which removes such features and simplifies loop structures is presented. This method, which is founded on the principle of separation of concerns is based on strongest postcondition calculations and congruent equivalence transformations. Not only does this method logically simplify loop structures; it also detects a range of defects including non-termination problems and unreachable code.

With programs growing in size and complexity, the quality and cost of developing and maintaining them are still deep concerns to software industries. Dynamically reconfigurable software, which is one paradigm for using component-based software, is a promising approach in reducing the developmental cost while increasing the quality and the reliability. For real-time embedded systems, a dynamically reconfigurable real-time software paradigm provides many major advantages over conventional real-time software development techniques. As with any other real-time software, dynamically reconfigurable software needs exception detection and handling mechanisms to satisfy reliability requirements. How-ever, the focus of developing reusable software has been on the structure of initialization and normal operation code within reusable components. This can make an application composed of reusable software non-deterministic and difficult to understand in the presence of errors. Even if 100 percent of modules are reused, there may still be the need for significant amounts of new code for error handling. Our goal is to create a structured exception handling mechanism for dynamically reconfigurable real-time software (DRRTS) that helps programmers to create reliable