Results 1 - 10
of
13
Exceptions and aspects: the devil is in the details.
- In SIGSOFT ’06/FSE-14: Proceedings of the 14th ACM SIGSOFT international symposium on Foundations of software engineering,
, 2006
"... ABSTRACT It is usually assumed that the implementation of exception handling can be better modularized by the use of aspectoriented programming (AOP). However, the trade-offs involved in using AOP with this goal are not well-understood. This paper presents an in-depth study of the adequacy of the A ..."
Abstract
-
Cited by 30 (4 self)
- Add to MetaCart
(Show Context)
ABSTRACT It is usually assumed that the implementation of exception handling can be better modularized by the use of aspectoriented programming (AOP). However, the trade-offs involved in using AOP with this goal are not well-understood. This paper presents an in-depth study of the adequacy of the AspectJ language for modularizing exception handling code. The study consisted in refactoring existing applications so that the code responsible for implementing heterogeneous error handling strategies was moved to separate aspects. We have performed quantitative assessments of four systemsthree object-oriented and one aspect-oriented -based on four quality attributes, namely separation of concerns, coupling, cohesion, and conciseness. Our investigation also included a multi-perspective analysis of the refactored systems, including (i) the reusability of the aspectized error handling code, (ii) the beneficial and harmful aspectization scenarios, and (iii) the scalability of AOP to aspectize exception handling in the presence of other crosscutting concerns.
Error propagation analysis for file systems
- In Proceedings of the ACM SIGPLAN 2009 Conference on Programming Language Design and Implementation
, 2009
"... Unchecked errors are especially pernicious in operating system file management code. Transient or permanent hardware failures are inevitable, and error-management bugs at the file system layer can cause silent, unrecoverable data corruption. We propose an interprocedural static analysis that tracks ..."
Abstract
-
Cited by 23 (8 self)
- Add to MetaCart
(Show Context)
Unchecked errors are especially pernicious in operating system file management code. Transient or permanent hardware failures are inevitable, and error-management bugs at the file system layer can cause silent, unrecoverable data corruption. We propose an interprocedural static analysis that tracks errors as they propagate through file system code. Our implementation detects overwritten, out-ofscope, and unsaved unchecked errors. Analysis of four widely-used Linux file system implementations (CIFS, ext3, IBM JFS and ReiserFS), a relatively new file system implementation (ext4), and shared virtual file system (VFS) code uncovers 312 error propagation bugs. Our flow- and context-sensitive approach produces more precise results than related techniques while providing better diagnostic information, including possible execution paths that demonstrate each bug found.
Ejflow: Taming exceptional control flows in aspect-oriented programming
- in: Proc. of 7th ACM Conference on Aspect-Oriented Software Development
, 2008
"... Many of the problems that stem from the use of exception handling are caused by the local way in which exceptions are handled. It demands that developers understand the source of an exception, the place where it is handled, and everything in between. As a consequence, exceptions easily get “out of c ..."
Abstract
-
Cited by 7 (2 self)
- Add to MetaCart
(Show Context)
Many of the problems that stem from the use of exception handling are caused by the local way in which exceptions are handled. It demands that developers understand the source of an exception, the place where it is handled, and everything in between. As a consequence, exceptions easily get “out of control” and, as system development progresses, exceptional control flows become less well-understood, with potentially negative consequences for the program maintainability and reliability. This paper presents an innovative aspect-oriented model for exception handling implementation. In contrast to other exception handling mechanisms, our model provides abstractions to explicitly describe global views of exceptional control flows. As a result, this new model makes it possible to understand exception flows from an end-to-end perspective by looking at a single part of the program. Also, it leverages existing pointcut languages to make the association of handlers with normal code more flexible. The implementation of our proposed model, called EJFlow, extends the AspectJ programming language with the aim of promoting enhanced robustness and program modularization. We evaluate qualitatively and quantitatively the proposed exception handling model through a case study targeting a real mobile application.
Software---Practice And Experience
- Software – Practice and Experience
, 2003
"... Aspects To apply authorization checks to Order and Product in Fig. 9, we don't change RoleBasedAuthorization but implement the pointcut of OrderProductAuthorization instead. The pointcut now also denotes those points in the execution of the program when instances of the Product class receive m ..."
Abstract
-
Cited by 4 (0 self)
- Add to MetaCart
(Show Context)
Aspects To apply authorization checks to Order and Product in Fig. 9, we don't change RoleBasedAuthorization but implement the pointcut of OrderProductAuthorization instead. The pointcut now also denotes those points in the execution of the program when instances of the Product class receive messages in addition to the points when instances of Order receive messages. OrderProductAuthorization thus fulfills a similar role as a binding in [12, 13].
On Exceptions, Events and Observer Chains
"... Modular understanding of behaviors and flows of exceptions may help in their better use and handling. Such reasoning tasks about exceptions face unique challenges in event-based implicit invocation (II) languages that allow subjects to implicitly invoke observers, and run the observers in a chain. I ..."
Abstract
-
Cited by 4 (2 self)
- Add to MetaCart
(Show Context)
Modular understanding of behaviors and flows of exceptions may help in their better use and handling. Such reasoning tasks about exceptions face unique challenges in event-based implicit invocation (II) languages that allow subjects to implicitly invoke observers, and run the observers in a chain. In this work, we illustrate these challenge in Ptolemy and propose Ptolemyχ that enables modular reasoning about behaviors and flows of exceptions for event announcement and handling. Ptolemyχ’s exception-aware specification expressions and boundary exceptions limit the set of (un)checked exceptions of subjects and observers of an event. Exceptional postconditions specify the behaviors of these exceptions. Greybox specifications specify the flows of these exceptions among the observers in the chain. Ptolemyχ’s type system and refinement rules enforce these specifications and thus enable its modular reasoning. We evaluate the utility of Ptolemyχ’s exception flow reasoning by applying it to understand a set of aspect-oriented (AO) bug patterns. We also present Ptolemyχ’s semantics including its sound static semantics.
A higher abstraction level using first-class inheritance relations
- IN ECOOP
, 2007
"... Although classes are a fundamental concept in object-oriented programming, a class itself cannot be built using general purpose classes as building blocks in a practical manner. High-level concepts like associations, bounded values, graph structures, and infrastructure for event mechanisms which for ..."
Abstract
-
Cited by 3 (3 self)
- Add to MetaCart
(Show Context)
Although classes are a fundamental concept in object-oriented programming, a class itself cannot be built using general purpose classes as building blocks in a practical manner. High-level concepts like associations, bounded values, graph structures, and infrastructure for event mechanisms which form the foundation of a class cannot be reused conveniently as components for classes. As a result, they are implemented over and over again. We raise the abstraction level of the language with a code inheritance relation for reusing general purpose classes as components for other classes. Features like mass renaming, first-class relations, high-level dependencies, component parameters, and indirect inheritance ensure that maximal reuse can be achieved with minimal effort. A case study shows a reduction of the code between 21 % and 36%, while the closest competitor only reduces the size between 3 % and 12%.
Abstractions for Improving, Creating, and Reusing Object-Oriented Programming Languages
, 2007
"... ..."
Abstract Data Type Components
, 2006
"... Although abstract data types are the foundation of object-oriented programming, the use of application independent ADTs as components for other ADTs is surprisingly difficult. No existing language allows the ADTs of high-level elements like associations, bounded values, graphs,... to be reused conve ..."
Abstract
-
Cited by 2 (2 self)
- Add to MetaCart
Although abstract data types are the foundation of object-oriented programming, the use of application independent ADTs as components for other ADTs is surprisingly difficult. No existing language allows the ADTs of high-level elements like associations, bounded values, graphs,... to be reused conveniently as components. As a result, their instance variables and methods are implemented over and over again. To allow such elements to be reused, we raise the abstraction level of the language by introducing a new multiple inheritance mechanism with two relations: is-a and has-a. The is-a relation is for subtyping and code inheritance, and is tailored for classification. The has-a relation is for code inheritance only, and is tailored for composition of ADTs. Using this inheritance mechanism, the implementation of the foundation of a program becomes a trivial task. A case study shows a 22 % decrease in the size of the code, while the second best inherit ance mechanism gets no further than 5%. In addition, the mechanism reduces the dependenc y between the implementation of a class and its hierarchy. We present a formal model of the inheritance mechanism, along with a proof of type soundness.
Assessing Intra-Application Exception Handling Reuse with Aspects
- XXIII BRAZILIAN SYMPOSIUM ON SOFTWARE ENGINEERING
, 2009
"... Recent studies have attempted to evaluate the benefits and drawbacks of using aspect-oriented programming to modularize exception handling code. In spite of their many interesting findings, these studies have not reached a consensus when it comes to the impact of aspectization on exception handler ..."
Abstract
-
Cited by 1 (0 self)
- Add to MetaCart
Recent studies have attempted to evaluate the benefits and drawbacks of using aspect-oriented programming to modularize exception handling code. In spite of their many interesting findings, these studies have not reached a consensus when it comes to the impact of aspectization on exception handler reuse. In fact, their results are sometimes in direct contradiction.In this paper we describe a study aiming to answer the question of whether AOP really promotes the implementation of reusable exception handling. We analyze reuse in a specific context: in terms of the number of duplicated or very similar error handlers that can be removed from a program when extracting error handling code to aspects. Our study targets three industrial-strength, medium-size software systems from different domains and employs a comprehensive set of concern-specific metrics.