Exception Handling Mechanisms Research Articles

Students’ Strategies for Exception Handling

This study discusses and presents various strategies employed by novice programmers concerning exception handling. The main contributions of this paper are as follows: we provide an analysis tool to measure the level of assimilation of exception handling mechanism; we present and analyse strategies to handle exceptions; we present and analyse solutions provided by novice programmers; we classify and analyse the participants' reflections concerning their solutions. Modern programming languages, such as Java, provide the programmer an elaborated object oriented exception mechanism; enable him to handle exceptions in a more convenient way. The aim of this study was to discover the strategies novice programmers are using to handle exceptions and whether they utilise the advantage of the modern exception handling mechanism. For that matter the participants (college students) had to provide a written solution to a given problem with a special focus on exception handling. In addition each of them was interviewed. The analysis of the solutions provided was carried out according to a set of software quality criteria (clarity, modularity and extensibility) adapted to exception handling characteristics. These criteria were used to explain the advantages and disadvantages of the solutions from a software engineering perspective. The solutions provided were also analysed according to a classification of levels of assimilation concerning the structure of exceptions, based on the SOLO taxonomy. The first level of assimilation refers to solutions in which no exception mechanism was used, and the errors were handled in the old fashion way (local handling or return of an error code). The fifth and last level refers to solutions that used adequate hierarchy of exception classes allowing easy extension according to future requirements and enabling the handling of multiple exception altogether or handle each separately. In between these levels there are strategies that used exception mechanisms without the exhausting of its advantages. The results obtained reveal that only few participants (7 out of 56) provided a solution that was classified to one of the two highest assimilation levels, while many (23 out of 56) did not use exception mechanism at all. The rest of the students (25 out of 56) used the exception mechanism poorly (i.e., used only Exception class or did not use hierarchy of exceptions). The participants had difficulties in utilising the advanced exception handling

Modeling and Verifying Concurrent Programs with Finite Chu Spaces

Finite Chu spaces are proposed for the modeling and verification of concurrent programs. In order to model not only typical concurrent behaviors but also modern exception handling and synchronization mechanisms, we design an enriched process algebra of Chu spaces from a practical point of view. To illustrate the power of finite Chu spaces and the process algebra while abstracting away from language-specific details, an imaginary concurrent programming language (ICL) is designed. A denotational semantics of ICL is presented using finite Chu spaces and the enriched process algebra. The valuation functions are fairly straightforward since the carefully designed operators have done much of the job. The enriched process algebra is also used as the specification language for Chu spaces, with which process-algebraic properties can be specified. Verification algorithms are presented with their time complexities discussed.

New update method with high-reliability for embedded system software

Concerning the shortages of traditional embedded software updates a new on-site update method with highreliability was proposed which achieved embedded system software updating by copying update files from a SD card to the flash partitions of the embedded device.On condition of fast update the compatibility detection of update files for faultavoidance the double-Bootloader design the test and verification of the update files and the exception handling mechanism were adopted to effectively improve fault-avoidance and fault-tolerance properties of the software.The high reliability of this method is proved through the reliability assessment based on the Nelson model and the application in the product.

Unveiling and taming liabilities of aspects in the presence of exceptions: A static analysis based approach

As aspects extend or replace existing functionality at specific join points in the code, their behavior may raise new exceptions, which can flow through the program execution in unexpected ways. Assuring the reliability of exception handling code in aspect-oriented (AO) systems is a challenging task. Testing the exception handling code is inherently difficult, since it is tricky to provoke all exceptions during tests, and the large number of different exceptions that can happen in a system may lead to the test-case explosion problem. Moreover, we have observed that some properties of AO programming (e.g., quantification, obliviousness) may conflict with characteristics of exception handling mechanisms, exacerbating existing problems (e.g., uncaught exceptions). The lack of verification approaches for exception handling code in AO systems stimulated the present work. This work presents a verification approach based on a static analysis tool, called SAFE, to check the reliability of exception handling code in AspectJ programs. We evaluated the effectiveness and feasibility of our approach in two complementary ways (i) by investigating if the SAFE tool is precise enough to uncover exception flow information and (ii) by applying the approach to three medium-sized ApectJ systems from different application domains.

Extending object-oriented languages with backward error recovery integrated support

One of the requirements of software robustness is controlling and managing runtime errors that might arise at certain points of application execution. In most object-oriented programming languages, this requirement is commonly implemented by means of exception handling. Although exception handling is a powerful tool to avoid system failure arising, there are still many situations where it is not sufficient to restore the system to a consistent state. Exception handling allows the developer to detect and locate errors, but it gives no information or tools to cover the error recovering task. Therefore, we propose an extension of the semantics of common object-oriented languages to restore the previous consistent state of the system in the presence of runtime errors, avoiding some of the tasks that exception-handling mechanisms delegate to developers. Our proposed solution is centered in the concept of “reconstructor”, a declarative component oriented to automatically return the system to its last stable state. Based on this concept, we develop a non-intrusive code enrichment tool for Java, and we apply it to a real application in order to check the feasibility of the proposal. We evaluated the performance of the resulting code, obtaining reasonable and viable rates and overload.

A safety shell for UML-RT projects structure and methods of the corresponding UML pattern

A safety shell pattern was defined based on a re-configuration management pattern and inspired by the architectural specifications in Specification PEARL. It is meant to be used for real-time applications to be developed with UML-RT as described. The implementation of the safety shell features as defined in Kornecki and Zalewski (Software Development for Real-Time Safety—Critical Applications. Software Engineering Workshop—Tutorial Notes, 29th Annual IEEE/NASA 03, pp 1–95, 2005), namely, its timing and state guards as well as I/O protection and exception handling mechanisms, is explained. The pattern is parameterised by defining the properties of its components as well as by defining the mapping between software and hardware architectures. Initial and alternative execution scenarios as well as the method for switching between them are defined. The goal pursued with the safety shell is to obtain clearly specified operation scenarios with well-defined transitions between them. To achieve safe and timely operation, the pattern must provide safety shell mechanisms for an application designed, i.e., enable its predictable deterministic and temporally predictable operation now and in the future.

Improving reliability of cooperative concurrent systems with exception flow analysis

Developers of fault-tolerant distributed systems need to guarantee that fault tolerance mechanisms they build are in themselves reliable. Otherwise, these mechanisms might in the end negatively affect overall system dependability, thus defeating the purpose of introducing fault tolerance into the system. To achieve the desired levels of reliability, mechanisms for detecting and handling errors should be developed rigorously or formally. We present an approach to modeling and verifying fault-tolerant distributed systems that use exception handling as the main fault tolerance mechanism. In the proposed approach, a formal model is employed to specify the structure of a system in terms of cooperating participants that handle exceptions in a coordinated manner, and coordinated atomic actions serve as representatives of mechanisms for exception handling in concurrent systems. We validate the approach through two case studies: (i) a system responsible for managing a production cell, and (ii) a medical control system. In both systems, the proposed approach has helped us to uncover design faults in the form of implicit assumptions and omissions in the original specifications.

Reasoning About Multi-Lingual Exception Handling Using RIPLS

Building multi-lingual software is a practical necessity. At present, with object-oriented programming the dominant paradigm, it is common to assemble software systems comprising components written in at least two different object-oriented languages. Modern object-oriented languages provide exception handling mechanisms as a means of enriching the signatures of methods with a specification of what to do if the method “fails”, i.e., cannot carry out its intended (normal) function for some reason. Indeed, Java and C++ (and many other object-oriented languages, including C#) have remarkably similar exception handling mechanisms. As we demonstrate, however, those exception handling mechanisms do not necessarily interoperate smoothly when used in multi-lingual software systems.We believe that our long-term goal of maximally effortless and error-free multi-lingual programming requires automated tools that are based on solid formal foundations. Toward that end, we have developed a formal language, which we call RIPLS, that can be used to rigorously study properties of multi-lingual software. In this paper, we demonstrate RIPLS and our approach by using it to study exception handling in multilingual object-oriented systems, and show how use of our methods can identify problems that standard techniques cannot. We then exhibit a correctly-working version of multi-lingual exception-handling and use our methods to confirm its correctness. Finally we discuss how experience with these RIPLS-based methods has informed our designs for automated tools that will implement correctly-working multi-lingual exception handling.This work makes a significant contribution by demonstrating that formal, theoretical foundations can be used to solve practical problems in multi-lingual software development.

Hidden truth behind .NET's exception handling today

The emergence of exception handling (EH) mechanisms in modern programming languages made available a different way of communicating errors between procedures. For years, programmers trusted in correct documentation of error codes returned by procedures to correctly handle erroneous situations. Now, they have to focus on the documentation of exceptions for the same effect. But to what extent can exception documentation be trusted? Moreover, is there enough documentation for exceptions? And in what way do these questions relate to the discussion on checked against unchecked exceptions? For a given set of Microsoft .NET applications, code and documentation were thoroughly parsed and compared. This showed that exception documentation tends to be scarce. In particular, it showed that 90% of exceptions are undocumented. Furthermore, programmers were demonstrated to be keener to document exceptions they explicitly throw while typically leaving exceptions resulting from method calls undocumented. This conclusion lead to another question: how do programmers use the EH mechanisms available in modern programming languages? More than 16 different .NET applications were examined in order to provide an answer. The major conclusion of this work is that exceptions are not being correctly used as an error-handling mechanism. These results contribute to the assessment of the effectiveness of the unchecked exceptions approach.

An Approach of Data-Flow Analysis Based on Exception Propagation Analysis

Exception handling is a technology that tests and handles exception. Exception propagation induces a control flow other than the main control flow, so it changes the data flows of programs. For data flow analysis of C++ programs to be correct and precise, the flows induced by exception propagation must be properly analyzed. Firstly, based on analyzing the exception handling mechanism and the effects of exception propagation on data flow analysis, the paper proposes a precise and efficient representation for C++ programs with exception handling constructs—control flow graph that contains exception propagation. The control flow graph can represent precisely the implicit control flow for a raised exception and exception propagation path. Then this paper proposes an efficient method to analyze the data flow of the programs that contain exception propagations, and some efficient algorithms are also presented. This method overcomes the limitations of previous incorrect analysis due to failing to account for the effects of exception propagation, and also provides a basis for automatic data flow analysis that contains exception propagation. Finally, it validates the usability of the method by a case study. The method can provide related informations for software engineering tasks such as structure testing, regression testing and program slicing.

An efficient and reliable object-oriented exception handling mechanism

This paper proposes an exception handling mechanism for developing reliable object-oriented systems based on analyzing some problems encountered in the C++ programming language. The exceptions are organized into a knowledge sharing inheritance hierarchy and the handlers can be defined within exception classes. This enables the information to be hidden. The separation between the normal codes and the exception handling codes makes the program neat and maintainable. It supports both the termination and the retry model. Binding the exception to the object responsible for its raise can solve the issue of matching the handler relying on only the exception type.

An interactive environment for beginning Java programmers

Building upon years of evolution in object-oriented programming language design, Java has emerged as the language of choice among many educators for teaching introductory computer science. A clean, type-safe language, Java provides a garbage collected heap and a comprehensive exception-handling mechanism. However, in spite of this support, many students in introductory computer science courses still find programming to be an overwhelming source of frustration. Linguistic concerns and programming mechanics demand so much attention that deeper concepts are often postponed for later courses, leaving students in introductory courses with the mistaken impression that computer science is a shallow discipline, concerned only with transcribing ideas into code, and not with the ideas themselves. JPie is a tightly integrated programming environment for live software construction in Java. JPie treats programming as an application in its own right, providing a visual representation of class definitions and supporting direct manipulation of graphical representations of programming abstractions and constructs. Exploiting Java’s reflection mechanism, JPie supports the notion of a dynamic class that can be modified while the program is running, thereby eliminating the edit–compile–test cycle. Following years of experience using Java as the vehicle for teaching introductory computer science, we have designed JPie to provide a more natural and fluid software development process that both raises the level of abstraction and eliminates many of the common pitfalls that beginning Java programmers face. This paper studies JPie from an educational perspective. We systematically review key programming abstractions and explain how JPie supports them in ways that keep beginning programmers focused on important ideas. Our experience using JPie in an introductory computer science survey course for non-majors is briefly discussed.

Static analysis to support the evolution of exception structure in object-oriented systems

Exception-handling mechanisms in modern programming languages provide a means to help software developers build robust applications by separating the normal control flow of a program from the control flow of the program under exceptional situations. Separating the exceptional structure from the code associated with normal operations bears some consequences. One consequence is that developers wishing to improve the robustness of a program must figure out which exceptions, if any, can flow to a point in the program. Unfortunately, in large programs, this exceptional control flow can be difficult, if not impossible, to determine.In this article, we present a model that encapsulates the minimal concepts necessary for a developer to determine exception flow for object-oriented languages that define exceptions as objects. Using these concepts, we describe why exception-flow information is needed to build and evolve robust programs. We then describe Jex, a static analysis tool we have developed to provide exception-flow information for Java systems based on this model. The Jex tool provides a view of the actual exception types that might arise at different program points and of the handlers that are present. Use of this tool on a collection of Java library and application source code demonstrates that the approach can be helpful to support both local and global improvements to the exception-handling structure of a system.

Exception Handling for Conflict Resolution in Cross-Organizational Workflows

Workflow management systems (WfMSs) are being increasingly deployed to deliver e-business transactions across organizational boundaries. To ensure a high service quality in such transactions, exception-handling schemes for conflict resolution are needed. The conflicts primarily arise due to failure of a task in workflow execution because of underlying application, or controlling WfMS component failures or insufficient user input. So far, little progress has been reported in addressing conflict resolution in cross-organizational business processes, though its importance has been recognized. In this paper, we identify the exception handling techniques that support conflict resolution in cross-organizational settings. In particular, we propose a novel, “bundled” exception-handling approach, which supports (1) exception knowledge sharing—sharing exception specifications and handling experiences, (2) coordinated exception handling, and (3) intelligent problem solving—using case based reasoning to reuse exception handing experiences. A prototype of this exception handling mechanism is developed and integrated as a part of the METEOR Workflow Management System. An evaluation of our approach is also presented through some sample workflow applications.

A comparative study of exception handling mechanisms for building dependable object-oriented software

Modern object-oriented systems have to cope with an increasing number of exceptional conditions and incorporate fault tolerance into systems' activities in order to meet dependability-related requirements. An exception handling mechanism is one of the most important schemes for detecting and recovering errors, and for structuring fault-tolerant activities in a system. The mechanisms that were ill designed can make an application unreliable and difficult to understand, maintain and reuse in the presence of faults. This paper surveys various exception mechanisms implemented in different object-oriented languages, evaluates and compares different designs. A taxonomy is developed to help address 10 basic technical aspects for a given exception handling proposal, including exception representation, external exceptions in signatures, separation between internal and external exceptions, attachment of handlers, handler binding, propagation of exceptions, continuation of the control flow, clean-up actions, reliability checks, and concurrent exception handling. Practical issues and difficulties are summarized, major trends in actual languages are identified, and directions for future work are suggested.

A side-by-side comparison of exception handling in Ada and Java

The purpose of this paper is to compare the exception handling mechanisms of Ada and Java. In order to be intelligible and useful to both communities, we have tried not to get into specific technical intricacies of the languages, perhaps sometimes at the cost of precision. Nevertheless, we decided to use the language-specific terminology whenever we write about a given language. We believe that the contrary would often lead to misunderstandings: a) the same term sometimes covers two different concepts, e.g. object, or b) when the concepts are basically the same, the features provided by the language can be largely different, making any unification impossible, e.g. task in Ada and thread in Java.Table 1 "Comparison of Terminology" shows the meanings and correspondences of the most important terms related directly or indirectly to exception handling in the two languages.We did not try to assess the merits of the two languages, not even with regard to exception handling. The issues are too many, and would by far exceed the scope of this paper: How to assess trade-offs between expressive power and performance, if ever a definite evaluation of performance is possible? How to assess language constructs whose "good" intent cannot be enforced? E.g. in Java, the "lazy" programmer can declare Throwable in a method's throws clause, instead of referring to specific exception classes. Where is the borderline between responsibility left to the programmer, and an admittedly error-prone construct in the language?Our goal was therefore to present facts, and facts only, as much as this is possible without any interpretation.

Designing robust Java programs with exceptions

Exception handling mechanisms are intended to help developers build robust systems. Although an exception handling mechanism provides a basis for structuring source code dealing with unusual situations, little information is available to help guide a developer in the appropriate application of the mechanism. In our experience, this lack of guidance leads to complex exception structures. In this paper, we reflect upon our experiences using the Java exception handling mechanism. Based on these experiences, we discuss two issues we believe underlie the difficulties encountered: exceptions are a global design problem, and exception sources are often difficult to predict in advance. We then describe a design approach, based on work by Litke for Ada programs, which we have used to simplify exception structure in existing Java programs.

Exception handling for PLC-based process control software

This paper deals with the possibility of introducing exception handling mechanisms into the specification and code of industrial process control software. Although exception handling is a very important aspect of process control applications, in most cases it is treated in an ad hoc and unstructured manner — which is mainly caused by the lack of appropriate constructs in programming languages for programmable logic controllers. A high degree of mastery of the development process can be achieved by applying an engineering process based upon life cycle and domain engineering concepts. The main result of domain engineering is a conceptual model of the domain in question. One of the elements of the conceptual model is the specification language with a defined exception handling construct. The exception handling construct is illustrated by a real application excerpt. It would be useful to include this exception handling construct into the Structured Text controller programming language.

Requirements and limits of a real-time transport system for distributed object computing middleware

With the advent of real-time extensions for communication middleware, new Quality of Service (QoS) aspects have to be considered. These include specification of constraints, timely delivery, validation and exception handling mechanisms. For that to b

LANGUAGES FOR REACTIVE SPECIFICATIONS: SYNCHRONY VS ASYNCHRONY

Asynchronous and Synchronous languages have been in use for the specification of reactive systems. One of the main distinguishing features of these two classes lies in the way nondeterminism is used for the specification of programs. From this viewpoint, we analyze CSP (a typical asynchronous language) and ESTEREL (a synchronous language). The synchronous language Esterel is based on the notions of determinism, input nondeterminacy and parallelism whereas CSP is built on the notions of nondeterminism, concurrency and distribution. The main objectives of the study are to assess: • The role of nondeterminism in the specification of the behaviour and realization of programs: A clear distinction between local and global nondeterminism enables us to distinguish between implementational nondeterminism and environmental/input nondeterminism. The results in this direction would enable one to achieve observable determinism where the implementational choices can be hidden and thus, analyze the program behaviour with reference to the real environmental nondeterminism in the specification. This leads to a proper refinement of specifications and aids in deriving distributed implementations of finite state transition systems that are not necessarily deterministic. • The implementability of asynchronous languages through synchronous languages. The implementability of asynchronous languages in synchronous languages not only provides a realistic implementation but also provides higher level abstractions (such as multi-process interactions) for reactive specifications using features such as broadcast, interrupts, exception handling mechanisms etc.