Aspect-Oriented Programming (AOP) is intended to ease situations that involve many kinds of code tangling. This paper reports on a study to investigate AOP's ability to ease tangling related to exception detection and handling. We took an existing framework written in Java, the JWAM framework, and partially reengineered its exception detection and handling aspects using AspectJ, an aspect-oriented programming extension to Java. We found that

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

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.

It is no longer possible to consider exception handling as a secondary issue in language design, or even worse, a mechanism added after the fact via a library approach. Exception handling is a primary feature in language design and must be integrated with other major features, including advanced control flow, objects, coroutines, concurrency, realtime and polymorphism. Integration is crucial as there are both obvious and subtle interactions between exception handling and other language features. Unfortunately, many exception handling mechanisms work only with a subset of the features and in the sequential domain. A framework for a comprehensive, easy to use, and extensible exception handling mechanism is presented for a concurrent, object-oriented environment. The environment includes language constructs with separate execution stacks, e.g., coroutines and tasks, so the exception environment is significantly more complex than the normal single-stack situation. The pros and cons of various exception features are examined, along with feature interaction with other language mechanisms. Both exception termination and resumption models are examined in this environment, and previous criticisms of the resumption model, a feature commonly missing in modern languages, are addressed. Index Terms---Exception handling, robustness, termination, resumption, concurrent, interrupts, object-oriented. 1

Optimizing exception handling is critical for programs that frequently throw exceptions. We observed that there are many such exception-intensive programs in various categories of Java programs. There are two commonly used exception handling techniques, stack unwinding and stack cutting. Stack unwinding optimizes the normal path, while stack cutting optimizes the exception handling path. However, there has been no single exception handling technique to optimize both paths. We propose a new technique called Exception-Directed Optimization (Edo), which optimizes exception-intensive programs without slowing down exception-minimal programs. Edo, a feedbackdirected dynamic optimization, consists of three steps, exception path profiling, exception path inlining, and throw elimination. Exception path profiling attempts to detect hot exception paths. Exception path inlining compiles the catching method in a hot exception path, inlining the rest of methods in the path. Throw elimination replaces a throw with the explicit control flow to the corresponding catch. We implemented Edo in IBM's production Justin -Time compiler, and obtained the experimental results, which show that, in SPECjvm98, it improved performance of exceptionintensive programs by up to 18.3% without a#ecting performance of exception-minimal programs at all. Categories and Subject Descriptors D.3 [Software]: Programming Languages; D.3.4 [Programming Languages]: Processors---incremental compilers, optimization, runtime environment General Terms Performance, Experimentation, Languages Keywords Feedback-directed dynamic optimization, dynamic compilers, exception handling, inlining Copyright c # 2001 by the Association for Computing Machinery, Inc. Permission to make digital or hard copies of part or a...

An electronic document may provide more information than its paper-based counter part. For example, in addition to text and images, a scientific document may consist of either the raw data or software that substantiates its hypothesis, ontology of its terms, a detailed comparison with its related work, etc. In this study, we explore: a) an environment that represents a document as a Web Service, and b) two alternative frameworks that facilitate discovery and retrieval of documents, namely, Jini and UDDI. We describe how each framework supports documents that reside on a cluster of nodes. These nodes might be dispersed across the Internet or in geographical proximity using an Intranet setting. In addition to detailing discovery and retrieval of documents, we describe how each framework supports data availability in the presence of load imbalance and node failures. One finding of this study is that these two frameworks are complementary and can be used in conjunction with one another.

this document is to provide an overview of the DESS methodology for its future users. It does however not directly address the tool support

this document is to provide an overview of the DESS methodology for its future users. It does however not directly address the tool support

Driven by the desire to facilitate more maintainable and robust systems, modern programming languages offer explicit constructs to facilitate the handling of exceptional events. The use of exceptions is common in user space programming, and is an integral part of common programming styles and best practices. In spite of this exceptions are rarely used in kernel-space. In fact, some operating systems, such as Linux, refrain altogether from using modern language constructs. We have implemented C++ kernel level run-time support for Linux, supporting the full range of C++ language abstractions, including run time type checking and exception handling. Through detailed instrumentation we show that introducing these mechanisms incurs negligible cost to normal program flow. Moreover, by enhancing the user level GNU g++ implementation we have reduced the cost of throwing and catching exceptions sufficiently, to make their use viable in a variety of in several important scenarios.