WEH '12: "Towards a Formal Model to ..."
Towards a Formal Model to Reason about Context-Aware Exception Handling
Lincoln S. Rocha and Rossana M. C. Andrade
(Federal University of Ceará, Brazil)
The context-awareness is a central aspect in the design of pervasive systems, characterizing their ability to adapt its structure and behavior. The context-aware exception handling (CAEH) is an existing approach employed to design exception handling in pervasive systems. In this approach, the context is used to define, detect, propagate, and handle exceptions. CAEH is a complex and error prone activity, needing designers' insights and domain expertise to identify and characterize contextual exceptions. However, despite the existence of formal methods to analyze the adaptive behavior of pervasive systems, such methods lack specific support to specify the CAEH behavior. In this paper, we propose a formal model to reason about the CAEH behavior. It comprises an extension of the Kripke Structure to model the context evolution of a pervasive system and a transformation function that derivates the CAEH control flow from that proposed structure.
@InProceedings{WEH12p27,
author = {Lincoln S. Rocha and Rossana M. C. Andrade},
title = {Towards a Formal Model to Reason about Context-Aware Exception Handling},
booktitle = {Proc.\ WEH},
publisher = {IEEE},
pages = {27--33},
doi = {},
year = {2012},
}
WEH '12: "Handling Contract Violations ..."
Handling Contract Violations in Java Card Using Explict Exception Channels
Juliana Araújo, Rafael Souza, Nélio Cacho, Anamaria Martins, and Plácido A. Souza Neto
(Federal University of Rio Grande do Norte, Brazil; Federal Institute of Rio Grande do Norte, Brazil)
Java Card is a version of Java developed to run on devices with severe storage and processing restrictions. The applets that run on these devices are frequently intended for use in critical, highly distributed, mobile conditions. This requires runtime verification approach based on Design by Contract to improve the safety of Java Card applications. However handling contract violation in Java Card applications is challenging due to their communication structure and platform restrictions. Additionally the Java Card exception handling mechanism requires that developers understand the source of an exception, the place where it is handled, and everything in between. As system development evolves, exceptional control flows become less well-understood, with negative consequences for the program maintainability and robustness. In this paper, we claim that such problem can be addressed by implementing an innovative exception handling model which provides abstractions to explicitly describe global views of exceptional control flows.
@InProceedings{WEH12p34,
author = {Juliana Araújo and Rafael Souza and Nélio Cacho and Anamaria Martins and Plácido A. Souza Neto},
title = {Handling Contract Violations in Java Card Using Explict Exception Channels},
booktitle = {Proc.\ WEH},
publisher = {IEEE},
pages = {34--40},
doi = {},
year = {2012},
}
WEH '12: "Separating Exceptional Concerns ..."
Separating Exceptional Concerns
Anya Helene Bagge
(University of Bergen, Norway)
Traditional error handling mechanisms, including exceptions, have several weaknesses that interfere with maintainability, flexibility and genericity in software: Error code is tangled with normal code; reporting is tangled with handling; and generic code is locked into specific ways of reporting and handling errors. We need to deal with errors in a declarative way, where the concerns of errors, error reporting and error handling are separated and dealt with individually by the programmer.
@InProceedings{WEH12p49,
author = {Anya Helene Bagge},
title = {Separating Exceptional Concerns},
booktitle = {Proc.\ WEH},
publisher = {IEEE},
pages = {49--51},
doi = {},
year = {2012},
}
WEH '12: "A Recommendation System for ..."
A Recommendation System for Exception Handling Code
Eiji Adachi Barbosa, Alessandro Garcia, and Mira Mezini
(PUC-Rio, Brazil; TU Darmstadt, Germany)
Even though exception handling mechanisms are part of most mainstream programming languages, software developers still struggle to implement proper exception handling code. In particular, they fail in implementing effective handler actions. This position paper discusses our ongoing work on implementing and assessing a recommendation system for recommending code fragments implementing exception handling code. These fragments are not meant to be reused as-is. Instead, they are meant to be used by the developers as examples of how to possibly handle their exceptions. The goal of the proposed recommendation system is to assist the learning process of software developers by providing concrete examples of exception handling code.
@InProceedings{WEH12p52,
author = {Eiji Adachi Barbosa and Alessandro Garcia and Mira Mezini},
title = {A Recommendation System for Exception Handling Code},
booktitle = {Proc.\ WEH},
publisher = {IEEE},
pages = {52--54},
doi = {},
year = {2012},
}
WEH '12: "An Implementation Mechanism ..."
An Implementation Mechanism for Tailorable Exceptional Flow
Steven te Brinke, Mark Laarakkers, Christoph Bockisch, and Lodewijk Bergmans
(University of Twente, Netherlands)
Decomposing software according to the structure of the problem domain makes it easier to manage its complexity. Such a decomposition requires a programming language that supports compositions matching those in the problem domain. However, current programming languages only offer a restricted set of control-flow related composition mechanisms, such as method invocation and exception handling. This limits developers in choosing the desired decomposition.
Previously, we showed that continuations are suitable for implementing various control-flow compositions. However, composing and refining these implementations requires new language features. In this paper, we outline requirements for control-flow composition and show how exception handling can be implemented using continuations, scopes and bindings.
@InProceedings{WEH12p22,
author = {Steven te Brinke and Mark Laarakkers and Christoph Bockisch and Lodewijk Bergmans},
title = {An Implementation Mechanism for Tailorable Exceptional Flow},
booktitle = {Proc.\ WEH},
publisher = {IEEE},
pages = {22--26},
doi = {},
year = {2012},
}
WEH '12: "An Implementation Mechanism ..."
An Implementation Mechanism for Tailorable Exceptional Flow
Steven te Brinke, Mark Laarakkers, Christoph Bockisch, and Lodewijk Bergmans
(University of Twente, Netherlands)
Decomposing software according to the structure of the problem domain makes it easier to manage its complexity. Such a decomposition requires a programming language that supports compositions matching those in the problem domain. However, current programming languages only offer a restricted set of control-flow related composition mechanisms, such as method invocation and exception handling. This limits developers in choosing the desired decomposition.
Previously, we showed that continuations are suitable for implementing various control-flow compositions. However, composing and refining these implementations requires new language features. In this paper, we outline requirements for control-flow composition and show how exception handling can be implemented using continuations, scopes and bindings.
@InProceedings{WEH12p22,
author = {Steven te Brinke and Mark Laarakkers and Christoph Bockisch and Lodewijk Bergmans},
title = {An Implementation Mechanism for Tailorable Exceptional Flow},
booktitle = {Proc.\ WEH},
publisher = {IEEE},
pages = {22--26},
doi = {},
year = {2012},
}
WEH '12: "An Implementation Mechanism ..."
An Implementation Mechanism for Tailorable Exceptional Flow
Steven te Brinke, Mark Laarakkers, Christoph Bockisch, and Lodewijk Bergmans
(University of Twente, Netherlands)
Decomposing software according to the structure of the problem domain makes it easier to manage its complexity. Such a decomposition requires a programming language that supports compositions matching those in the problem domain. However, current programming languages only offer a restricted set of control-flow related composition mechanisms, such as method invocation and exception handling. This limits developers in choosing the desired decomposition.
Previously, we showed that continuations are suitable for implementing various control-flow compositions. However, composing and refining these implementations requires new language features. In this paper, we outline requirements for control-flow composition and show how exception handling can be implemented using continuations, scopes and bindings.
@InProceedings{WEH12p22,
author = {Steven te Brinke and Mark Laarakkers and Christoph Bockisch and Lodewijk Bergmans},
title = {An Implementation Mechanism for Tailorable Exceptional Flow},
booktitle = {Proc.\ WEH},
publisher = {IEEE},
pages = {22--26},
doi = {},
year = {2012},
}
WEH '12: "Usability Challenges in Exception ..."
Usability Challenges in Exception Handling
Roy Krischer and Peter A. Buhr
(University of Waterloo, Canada)
Two language mechanisms are presented and assessed for assisting understanding of exception complexity. First, passive and active exception assertions dynamically check if the reason for an exception raise matches with the purpose of a matching handler. A passive assertion is a check when an exception propagates out of a block it guards. The active form adds probabilistically injection of exceptions to provide more comprehensive testing. Second, runtime exception information is logged for dynamic query to check current handling status and provide a history of exceptional events.
@InProceedings{WEH12p7,
author = {Roy Krischer and Peter A. Buhr},
title = {Usability Challenges in Exception Handling},
booktitle = {Proc.\ WEH},
publisher = {IEEE},
pages = {7--13},
doi = {},
year = {2012},
}
WEH '12: "Handling Exceptions in Programs ..."
Handling Exceptions in Programs with Hidden Concurrency: New Challenges for Old Solutions
Alcides Fonseca and Bruno Cabral
(University of Coimbra, Portugal)
Multi-core processors are present in everyone’s daily life. Consequently, concurrent programming has re-emerged as a pressing concern for everyone interested in exploring all the potential computational power in these machines. But, the emergence of new concurrency models and programming languages also brings new challenges in terms of how one can deal with abnormal occurrences, much due to the heterogenous parallel control flow. Unexpectedly, sequential Exception Handling models remain as the most used tool for robustness, even in the most recent concurrent programming languages. Though, the appearance of more complex models, such as programming languages with implicit concurrency, might pose a challenge too big for these sequential mechanisms. In this article we will provide evidences why such models are not generally suited to deal with faults in programs with implicit concurrency and, in the light of more recent advances in concurrent Exception Handling, we will discuss the attributes of a model for addressing this problem.
@InProceedings{WEH12p14,
author = {Alcides Fonseca and Bruno Cabral},
title = {Handling Exceptions in Programs with Hidden Concurrency: New Challenges for Old Solutions},
booktitle = {Proc.\ WEH},
publisher = {IEEE},
pages = {14--17},
doi = {},
year = {2012},
}
WEH '12: "Handling Contract Violations ..."
Handling Contract Violations in Java Card Using Explict Exception Channels
Juliana Araújo, Rafael Souza, Nélio Cacho, Anamaria Martins, and Plácido A. Souza Neto
(Federal University of Rio Grande do Norte, Brazil; Federal Institute of Rio Grande do Norte, Brazil)
Java Card is a version of Java developed to run on devices with severe storage and processing restrictions. The applets that run on these devices are frequently intended for use in critical, highly distributed, mobile conditions. This requires runtime verification approach based on Design by Contract to improve the safety of Java Card applications. However handling contract violation in Java Card applications is challenging due to their communication structure and platform restrictions. Additionally the Java Card exception handling mechanism requires that developers understand the source of an exception, the place where it is handled, and everything in between. As system development evolves, exceptional control flows become less well-understood, with negative consequences for the program maintainability and robustness. In this paper, we claim that such problem can be addressed by implementing an innovative exception handling model which provides abstractions to explicitly describe global views of exceptional control flows.
@InProceedings{WEH12p34,
author = {Juliana Araújo and Rafael Souza and Nélio Cacho and Anamaria Martins and Plácido A. Souza Neto},
title = {Handling Contract Violations in Java Card Using Explict Exception Channels},
booktitle = {Proc.\ WEH},
publisher = {IEEE},
pages = {34--40},
doi = {},
year = {2012},
}
WEH '12: "Measurement of Exception-Handling ..."
Measurement of Exception-Handling Code: An Exploratory Study
Keith Ó Dúlaigh, James F. Power, and Peter J. Clarke
(National University of Ireland, Ireland; Florida International University, USA)
This paper presents some preliminary results from an empirical study of 12 Java applications from the Qualitas corpus. We measure the quantity and distribution of exception-handling constructs, and study their change as the systems evolve through several versions.
@InProceedings{WEH12p55,
author = {Keith Ó Dúlaigh and James F. Power and Peter J. Clarke},
title = {Measurement of Exception-Handling Code: An Exploratory Study},
booktitle = {Proc.\ WEH},
publisher = {IEEE},
pages = {55--61},
doi = {},
year = {2012},
}
WEH '12: "Modular Fault Handling in ..."
Modular Fault Handling in a Network-Transparent Programming Language
Géry Debongnie, Raphäel Collet, Sébastien Doeraene, and Peter Van Roy
(Université Catholique de Louvain, Belgium)
A programming language is network-transparent if the same program code executes with the same results, whether it is run in a centralized or distributed setting, provided there is no partial failure. The Erlang programming language is network-transparent and handle failures by message passing. We propose in this paper a generalization of the Erlang failure handling model which can be used for more expressive network-transparent languages.
The new design introduces two concepts: entity fault states and fault streams. The failure of an entity is modeled in the system as a language entity, and is visible to the programmer via its corresponding fault stream. We also describe an implementation in Mozart 1.4.0. Evaluation shows that this model incurs a slight overhead in performance, but yields much more modular program code.
@InProceedings{WEH12p18,
author = {Géry Debongnie and Raphäel Collet and Sébastien Doeraene and Peter Van Roy},
title = {Modular Fault Handling in a Network-Transparent Programming Language},
booktitle = {Proc.\ WEH},
publisher = {IEEE},
pages = {18--21},
doi = {},
year = {2012},
}
WEH '12: "Modular Fault Handling in ..."
Modular Fault Handling in a Network-Transparent Programming Language
Géry Debongnie, Raphäel Collet, Sébastien Doeraene, and Peter Van Roy
(Université Catholique de Louvain, Belgium)
A programming language is network-transparent if the same program code executes with the same results, whether it is run in a centralized or distributed setting, provided there is no partial failure. The Erlang programming language is network-transparent and handle failures by message passing. We propose in this paper a generalization of the Erlang failure handling model which can be used for more expressive network-transparent languages.
The new design introduces two concepts: entity fault states and fault streams. The failure of an entity is modeled in the system as a language entity, and is visible to the programmer via its corresponding fault stream. We also describe an implementation in Mozart 1.4.0. Evaluation shows that this model incurs a slight overhead in performance, but yields much more modular program code.
@InProceedings{WEH12p18,
author = {Géry Debongnie and Raphäel Collet and Sébastien Doeraene and Peter Van Roy},
title = {Modular Fault Handling in a Network-Transparent Programming Language},
booktitle = {Proc.\ WEH},
publisher = {IEEE},
pages = {18--21},
doi = {},
year = {2012},
}
WEH '12: "Modular Fault Handling in ..."
Modular Fault Handling in a Network-Transparent Programming Language
Géry Debongnie, Raphäel Collet, Sébastien Doeraene, and Peter Van Roy
(Université Catholique de Louvain, Belgium)
A programming language is network-transparent if the same program code executes with the same results, whether it is run in a centralized or distributed setting, provided there is no partial failure. The Erlang programming language is network-transparent and handle failures by message passing. We propose in this paper a generalization of the Erlang failure handling model which can be used for more expressive network-transparent languages.
The new design introduces two concepts: entity fault states and fault streams. The failure of an entity is modeled in the system as a language entity, and is visible to the programmer via its corresponding fault stream. We also describe an implementation in Mozart 1.4.0. Evaluation shows that this model incurs a slight overhead in performance, but yields much more modular program code.
@InProceedings{WEH12p18,
author = {Géry Debongnie and Raphäel Collet and Sébastien Doeraene and Peter Van Roy},
title = {Modular Fault Handling in a Network-Transparent Programming Language},
booktitle = {Proc.\ WEH},
publisher = {IEEE},
pages = {18--21},
doi = {},
year = {2012},
}
WEH '12: "Handling Exceptions in Programs ..."
Handling Exceptions in Programs with Hidden Concurrency: New Challenges for Old Solutions
Alcides Fonseca and Bruno Cabral
(University of Coimbra, Portugal)
Multi-core processors are present in everyone’s daily life. Consequently, concurrent programming has re-emerged as a pressing concern for everyone interested in exploring all the potential computational power in these machines. But, the emergence of new concurrency models and programming languages also brings new challenges in terms of how one can deal with abnormal occurrences, much due to the heterogenous parallel control flow. Unexpectedly, sequential Exception Handling models remain as the most used tool for robustness, even in the most recent concurrent programming languages. Though, the appearance of more complex models, such as programming languages with implicit concurrency, might pose a challenge too big for these sequential mechanisms. In this article we will provide evidences why such models are not generally suited to deal with faults in programs with implicit concurrency and, in the light of more recent advances in concurrent Exception Handling, we will discuss the attributes of a model for addressing this problem.
@InProceedings{WEH12p14,
author = {Alcides Fonseca and Bruno Cabral},
title = {Handling Exceptions in Programs with Hidden Concurrency: New Challenges for Old Solutions},
booktitle = {Proc.\ WEH},
publisher = {IEEE},
pages = {14--17},
doi = {},
year = {2012},
}
WEH '12: "A Recommendation System for ..."
A Recommendation System for Exception Handling Code
Eiji Adachi Barbosa, Alessandro Garcia, and Mira Mezini
(PUC-Rio, Brazil; TU Darmstadt, Germany)
Even though exception handling mechanisms are part of most mainstream programming languages, software developers still struggle to implement proper exception handling code. In particular, they fail in implementing effective handler actions. This position paper discusses our ongoing work on implementing and assessing a recommendation system for recommending code fragments implementing exception handling code. These fragments are not meant to be reused as-is. Instead, they are meant to be used by the developers as examples of how to possibly handle their exceptions. The goal of the proposed recommendation system is to assist the learning process of software developers by providing concrete examples of exception handling code.
@InProceedings{WEH12p52,
author = {Eiji Adachi Barbosa and Alessandro Garcia and Mira Mezini},
title = {A Recommendation System for Exception Handling Code},
booktitle = {Proc.\ WEH},
publisher = {IEEE},
pages = {52--54},
doi = {},
year = {2012},
}
WEH '12: "Concrete Error Handling Mechanisms ..."
Concrete Error Handling Mechanisms Should Be Configurable
Tero Hasu
(University of Bergen, Norway)
We argue that programmers should not need to decide on a specific error handling mechanism when implementing a C or C++ library. Rather, it should be possible to make that decision at configuration time in order to achieve better portability and more convenient use of libraries.
@InProceedings{WEH12p46,
author = {Tero Hasu},
title = {Concrete Error Handling Mechanisms Should Be Configurable},
booktitle = {Proc.\ WEH},
publisher = {IEEE},
pages = {46--48},
doi = {},
year = {2012},
}
WEH '12: "Supporting the Evolution of ..."
Supporting the Evolution of Exception Handling in Component-Based Product Line Architecture
Bruno de A. Iizuka, Amanda S. Nascimento, Leonardo P. Tizzei, and Cecília M. F. Rubira
(University of Campinas, Brazil)
Separation of concerns is one of the important goals of exception handling in order to keep separated the normal and the exceptional behaviour of a software system. Therefore it promotes both reuse and maintainability of normal and error handling code. In this work, our focus is to present how we can use the notion of aspect-connector for designing software variabilities related to different handling strategies in the context of a software product line. In particular, Connector-VP is used to support choices of different handlers depending on the set of selected features. Thus it realizes the binding between the normal behaviour and the selected exception handler.
@InProceedings{WEH12p62,
author = {Bruno de A. Iizuka and Amanda S. Nascimento and Leonardo P. Tizzei and Cecília M. F. Rubira},
title = {Supporting the Evolution of Exception Handling in Component-Based Product Line Architecture},
booktitle = {Proc.\ WEH},
publisher = {IEEE},
pages = {62--64},
doi = {},
year = {2012},
}
WEH '12: "Usability Challenges in Exception ..."
Usability Challenges in Exception Handling
Roy Krischer and Peter A. Buhr
(University of Waterloo, Canada)
Two language mechanisms are presented and assessed for assisting understanding of exception complexity. First, passive and active exception assertions dynamically check if the reason for an exception raise matches with the purpose of a matching handler. A passive assertion is a check when an exception propagates out of a block it guards. The active form adds probabilistically injection of exceptions to provide more comprehensive testing. Second, runtime exception information is logged for dynamic query to check current handling status and provide a history of exceptional events.
@InProceedings{WEH12p7,
author = {Roy Krischer and Peter A. Buhr},
title = {Usability Challenges in Exception Handling},
booktitle = {Proc.\ WEH},
publisher = {IEEE},
pages = {7--13},
doi = {},
year = {2012},
}
WEH '12: "An Implementation Mechanism ..."
An Implementation Mechanism for Tailorable Exceptional Flow
Steven te Brinke, Mark Laarakkers, Christoph Bockisch, and Lodewijk Bergmans
(University of Twente, Netherlands)
Decomposing software according to the structure of the problem domain makes it easier to manage its complexity. Such a decomposition requires a programming language that supports compositions matching those in the problem domain. However, current programming languages only offer a restricted set of control-flow related composition mechanisms, such as method invocation and exception handling. This limits developers in choosing the desired decomposition.
Previously, we showed that continuations are suitable for implementing various control-flow compositions. However, composing and refining these implementations requires new language features. In this paper, we outline requirements for control-flow composition and show how exception handling can be implemented using continuations, scopes and bindings.
@InProceedings{WEH12p22,
author = {Steven te Brinke and Mark Laarakkers and Christoph Bockisch and Lodewijk Bergmans},
title = {An Implementation Mechanism for Tailorable Exceptional Flow},
booktitle = {Proc.\ WEH},
publisher = {IEEE},
pages = {22--26},
doi = {},
year = {2012},
}
WEH '12: "The Role of Context in Exception-Driven ..."
The Role of Context in Exception-Driven Rework
Xiang Zhao, Barbara Staudt Lerner, and Leon J. Osterweil
(University of Massachusetts at Amherst, USA; Mount Holyoke College, USA)
Exception-driven rework occurs commonly in software development. In this paper, we describe a simple refactoring process, showing the use of the exception-driven rework exception handling pattern within it. We also discuss the important role that context plays in supporting the user during rework in helping the user keep track of the tasks being worked on and to facilitate resumption of normal activities upon completion of the exception handling work. The example process is specified in the Little-JIL process definition language. The use of context information in supporting the user is illustrated using a Data Derivation Graph (DDG), a graph that is automatically generated to document the ways in which artifact values are evolved during execution of a Little-JIL process.
@InProceedings{WEH12p41,
author = {Xiang Zhao and Barbara Staudt Lerner and Leon J. Osterweil},
title = {The Role of Context in Exception-Driven Rework},
booktitle = {Proc.\ WEH},
publisher = {IEEE},
pages = {41--45},
doi = {},
year = {2012},
}
WEH '12: "Handling Contract Violations ..."
Handling Contract Violations in Java Card Using Explict Exception Channels
Juliana Araújo, Rafael Souza, Nélio Cacho, Anamaria Martins, and Plácido A. Souza Neto
(Federal University of Rio Grande do Norte, Brazil; Federal Institute of Rio Grande do Norte, Brazil)
Java Card is a version of Java developed to run on devices with severe storage and processing restrictions. The applets that run on these devices are frequently intended for use in critical, highly distributed, mobile conditions. This requires runtime verification approach based on Design by Contract to improve the safety of Java Card applications. However handling contract violation in Java Card applications is challenging due to their communication structure and platform restrictions. Additionally the Java Card exception handling mechanism requires that developers understand the source of an exception, the place where it is handled, and everything in between. As system development evolves, exceptional control flows become less well-understood, with negative consequences for the program maintainability and robustness. In this paper, we claim that such problem can be addressed by implementing an innovative exception handling model which provides abstractions to explicitly describe global views of exceptional control flows.
@InProceedings{WEH12p34,
author = {Juliana Araújo and Rafael Souza and Nélio Cacho and Anamaria Martins and Plácido A. Souza Neto},
title = {Handling Contract Violations in Java Card Using Explict Exception Channels},
booktitle = {Proc.\ WEH},
publisher = {IEEE},
pages = {34--40},
doi = {},
year = {2012},
}
WEH '12: "Can Asynchronous Exceptions ..."
Can Asynchronous Exceptions Expire?
Benjamin Morandi and Bertrand Meyer
(ETH Zurich, Switzerland)
A multitude of asynchronous exception mechanisms have been proposed. They specify where and when an asynchronous exception propagates. We highlight another aspect that has largely been overlooked: can an asynchronous exception expire? We discuss scenarios where it is meaningful for an asynchronous exception to expire. We further elaborate on one of the scenarios, thereby outlining an asynchronous exception mechanism for the SCOOP concurrency model.
@InProceedings{WEH12p4,
author = {Benjamin Morandi and Bertrand Meyer},
title = {Can Asynchronous Exceptions Expire?},
booktitle = {Proc.\ WEH},
publisher = {IEEE},
pages = {4--6},
doi = {},
year = {2012},
}
WEH '12: "A Recommendation System for ..."
A Recommendation System for Exception Handling Code
Eiji Adachi Barbosa, Alessandro Garcia, and Mira Mezini
(PUC-Rio, Brazil; TU Darmstadt, Germany)
Even though exception handling mechanisms are part of most mainstream programming languages, software developers still struggle to implement proper exception handling code. In particular, they fail in implementing effective handler actions. This position paper discusses our ongoing work on implementing and assessing a recommendation system for recommending code fragments implementing exception handling code. These fragments are not meant to be reused as-is. Instead, they are meant to be used by the developers as examples of how to possibly handle their exceptions. The goal of the proposed recommendation system is to assist the learning process of software developers by providing concrete examples of exception handling code.
@InProceedings{WEH12p52,
author = {Eiji Adachi Barbosa and Alessandro Garcia and Mira Mezini},
title = {A Recommendation System for Exception Handling Code},
booktitle = {Proc.\ WEH},
publisher = {IEEE},
pages = {52--54},
doi = {},
year = {2012},
}
WEH '12: "Can Asynchronous Exceptions ..."
Can Asynchronous Exceptions Expire?
Benjamin Morandi and Bertrand Meyer
(ETH Zurich, Switzerland)
A multitude of asynchronous exception mechanisms have been proposed. They specify where and when an asynchronous exception propagates. We highlight another aspect that has largely been overlooked: can an asynchronous exception expire? We discuss scenarios where it is meaningful for an asynchronous exception to expire. We further elaborate on one of the scenarios, thereby outlining an asynchronous exception mechanism for the SCOOP concurrency model.
@InProceedings{WEH12p4,
author = {Benjamin Morandi and Bertrand Meyer},
title = {Can Asynchronous Exceptions Expire?},
booktitle = {Proc.\ WEH},
publisher = {IEEE},
pages = {4--6},
doi = {},
year = {2012},
}
WEH '12: "Supporting the Evolution of ..."
Supporting the Evolution of Exception Handling in Component-Based Product Line Architecture
Bruno de A. Iizuka, Amanda S. Nascimento, Leonardo P. Tizzei, and Cecília M. F. Rubira
(University of Campinas, Brazil)
Separation of concerns is one of the important goals of exception handling in order to keep separated the normal and the exceptional behaviour of a software system. Therefore it promotes both reuse and maintainability of normal and error handling code. In this work, our focus is to present how we can use the notion of aspect-connector for designing software variabilities related to different handling strategies in the context of a software product line. In particular, Connector-VP is used to support choices of different handlers depending on the set of selected features. Thus it realizes the binding between the normal behaviour and the selected exception handler.
@InProceedings{WEH12p62,
author = {Bruno de A. Iizuka and Amanda S. Nascimento and Leonardo P. Tizzei and Cecília M. F. Rubira},
title = {Supporting the Evolution of Exception Handling in Component-Based Product Line Architecture},
booktitle = {Proc.\ WEH},
publisher = {IEEE},
pages = {62--64},
doi = {},
year = {2012},
}
WEH '12: "Handling Contract Violations ..."
Handling Contract Violations in Java Card Using Explict Exception Channels
Juliana Araújo, Rafael Souza, Nélio Cacho, Anamaria Martins, and Plácido A. Souza Neto
(Federal University of Rio Grande do Norte, Brazil; Federal Institute of Rio Grande do Norte, Brazil)
Java Card is a version of Java developed to run on devices with severe storage and processing restrictions. The applets that run on these devices are frequently intended for use in critical, highly distributed, mobile conditions. This requires runtime verification approach based on Design by Contract to improve the safety of Java Card applications. However handling contract violation in Java Card applications is challenging due to their communication structure and platform restrictions. Additionally the Java Card exception handling mechanism requires that developers understand the source of an exception, the place where it is handled, and everything in between. As system development evolves, exceptional control flows become less well-understood, with negative consequences for the program maintainability and robustness. In this paper, we claim that such problem can be addressed by implementing an innovative exception handling model which provides abstractions to explicitly describe global views of exceptional control flows.
@InProceedings{WEH12p34,
author = {Juliana Araújo and Rafael Souza and Nélio Cacho and Anamaria Martins and Plácido A. Souza Neto},
title = {Handling Contract Violations in Java Card Using Explict Exception Channels},
booktitle = {Proc.\ WEH},
publisher = {IEEE},
pages = {34--40},
doi = {},
year = {2012},
}
WEH '12: "Measurement of Exception-Handling ..."
Measurement of Exception-Handling Code: An Exploratory Study
Keith Ó Dúlaigh, James F. Power, and Peter J. Clarke
(National University of Ireland, Ireland; Florida International University, USA)
This paper presents some preliminary results from an empirical study of 12 Java applications from the Qualitas corpus. We measure the quantity and distribution of exception-handling constructs, and study their change as the systems evolve through several versions.
@InProceedings{WEH12p55,
author = {Keith Ó Dúlaigh and James F. Power and Peter J. Clarke},
title = {Measurement of Exception-Handling Code: An Exploratory Study},
booktitle = {Proc.\ WEH},
publisher = {IEEE},
pages = {55--61},
doi = {},
year = {2012},
}
WEH '12: "The Role of Context in Exception-Driven ..."
The Role of Context in Exception-Driven Rework
Xiang Zhao, Barbara Staudt Lerner, and Leon J. Osterweil
(University of Massachusetts at Amherst, USA; Mount Holyoke College, USA)
Exception-driven rework occurs commonly in software development. In this paper, we describe a simple refactoring process, showing the use of the exception-driven rework exception handling pattern within it. We also discuss the important role that context plays in supporting the user during rework in helping the user keep track of the tasks being worked on and to facilitate resumption of normal activities upon completion of the exception handling work. The example process is specified in the Little-JIL process definition language. The use of context information in supporting the user is illustrated using a Data Derivation Graph (DDG), a graph that is automatically generated to document the ways in which artifact values are evolved during execution of a Little-JIL process.
@InProceedings{WEH12p41,
author = {Xiang Zhao and Barbara Staudt Lerner and Leon J. Osterweil},
title = {The Role of Context in Exception-Driven Rework},
booktitle = {Proc.\ WEH},
publisher = {IEEE},
pages = {41--45},
doi = {},
year = {2012},
}
WEH '12: "Measurement of Exception-Handling ..."
Measurement of Exception-Handling Code: An Exploratory Study
Keith Ó Dúlaigh, James F. Power, and Peter J. Clarke
(National University of Ireland, Ireland; Florida International University, USA)
This paper presents some preliminary results from an empirical study of 12 Java applications from the Qualitas corpus. We measure the quantity and distribution of exception-handling constructs, and study their change as the systems evolve through several versions.
@InProceedings{WEH12p55,
author = {Keith Ó Dúlaigh and James F. Power and Peter J. Clarke},
title = {Measurement of Exception-Handling Code: An Exploratory Study},
booktitle = {Proc.\ WEH},
publisher = {IEEE},
pages = {55--61},
doi = {},
year = {2012},
}
WEH '12: "Towards a Formal Model to ..."
Towards a Formal Model to Reason about Context-Aware Exception Handling
Lincoln S. Rocha and Rossana M. C. Andrade
(Federal University of Ceará, Brazil)
The context-awareness is a central aspect in the design of pervasive systems, characterizing their ability to adapt its structure and behavior. The context-aware exception handling (CAEH) is an existing approach employed to design exception handling in pervasive systems. In this approach, the context is used to define, detect, propagate, and handle exceptions. CAEH is a complex and error prone activity, needing designers' insights and domain expertise to identify and characterize contextual exceptions. However, despite the existence of formal methods to analyze the adaptive behavior of pervasive systems, such methods lack specific support to specify the CAEH behavior. In this paper, we propose a formal model to reason about the CAEH behavior. It comprises an extension of the Kripke Structure to model the context evolution of a pervasive system and a transformation function that derivates the CAEH control flow from that proposed structure.
@InProceedings{WEH12p27,
author = {Lincoln S. Rocha and Rossana M. C. Andrade},
title = {Towards a Formal Model to Reason about Context-Aware Exception Handling},
booktitle = {Proc.\ WEH},
publisher = {IEEE},
pages = {27--33},
doi = {},
year = {2012},
}
WEH '12: "Supporting the Evolution of ..."
Supporting the Evolution of Exception Handling in Component-Based Product Line Architecture
Bruno de A. Iizuka, Amanda S. Nascimento, Leonardo P. Tizzei, and Cecília M. F. Rubira
(University of Campinas, Brazil)
Separation of concerns is one of the important goals of exception handling in order to keep separated the normal and the exceptional behaviour of a software system. Therefore it promotes both reuse and maintainability of normal and error handling code. In this work, our focus is to present how we can use the notion of aspect-connector for designing software variabilities related to different handling strategies in the context of a software product line. In particular, Connector-VP is used to support choices of different handlers depending on the set of selected features. Thus it realizes the binding between the normal behaviour and the selected exception handler.
@InProceedings{WEH12p62,
author = {Bruno de A. Iizuka and Amanda S. Nascimento and Leonardo P. Tizzei and Cecília M. F. Rubira},
title = {Supporting the Evolution of Exception Handling in Component-Based Product Line Architecture},
booktitle = {Proc.\ WEH},
publisher = {IEEE},
pages = {62--64},
doi = {},
year = {2012},
}
WEH '12: "Handling Contract Violations ..."
Handling Contract Violations in Java Card Using Explict Exception Channels
Juliana Araújo, Rafael Souza, Nélio Cacho, Anamaria Martins, and Plácido A. Souza Neto
(Federal University of Rio Grande do Norte, Brazil; Federal Institute of Rio Grande do Norte, Brazil)
Java Card is a version of Java developed to run on devices with severe storage and processing restrictions. The applets that run on these devices are frequently intended for use in critical, highly distributed, mobile conditions. This requires runtime verification approach based on Design by Contract to improve the safety of Java Card applications. However handling contract violation in Java Card applications is challenging due to their communication structure and platform restrictions. Additionally the Java Card exception handling mechanism requires that developers understand the source of an exception, the place where it is handled, and everything in between. As system development evolves, exceptional control flows become less well-understood, with negative consequences for the program maintainability and robustness. In this paper, we claim that such problem can be addressed by implementing an innovative exception handling model which provides abstractions to explicitly describe global views of exceptional control flows.
@InProceedings{WEH12p34,
author = {Juliana Araújo and Rafael Souza and Nélio Cacho and Anamaria Martins and Plácido A. Souza Neto},
title = {Handling Contract Violations in Java Card Using Explict Exception Channels},
booktitle = {Proc.\ WEH},
publisher = {IEEE},
pages = {34--40},
doi = {},
year = {2012},
}
WEH '12: "Making Exceptions on Exception ..."
Making Exceptions on Exception Handling
Tao Xie and Suresh Thummalapenta
(North Carolina State University, USA; IBM Research, India)
The exception-handling mechanism has been widely adopted to deal with exception conditions that may arise during program executions. To produce high-quality programs, developers are expected to handle these exception conditions and take necessary recovery or resource-releasing actions. Failing to handle these exception conditions can lead to not only performance degradation, but also critical issues. Developers can write formal specifications to capture expected exception-handling behavior, and then apply tools to automatically analyze program code for detecting specification violations. However, in practice, developers rarely write formal specifications. To address this issue, mining techniques have been used to mine common exception-handling behavior out of program code. In this paper, we discuss challenges and achievements in precisely specifying and mining formal exception-handling specifications, as tackled by our previous work. Our key insight is that expected exception-handling behavior may be "conditional" or may need to accommodate "exceptional" cases.
@InProceedings{WEH12p1,
author = {Tao Xie and Suresh Thummalapenta},
title = {Making Exceptions on Exception Handling},
booktitle = {Proc.\ WEH},
publisher = {IEEE},
pages = {1--3},
doi = {},
year = {2012},
}
WEH '12: "Supporting the Evolution of ..."
Supporting the Evolution of Exception Handling in Component-Based Product Line Architecture
Bruno de A. Iizuka, Amanda S. Nascimento, Leonardo P. Tizzei, and Cecília M. F. Rubira
(University of Campinas, Brazil)
Separation of concerns is one of the important goals of exception handling in order to keep separated the normal and the exceptional behaviour of a software system. Therefore it promotes both reuse and maintainability of normal and error handling code. In this work, our focus is to present how we can use the notion of aspect-connector for designing software variabilities related to different handling strategies in the context of a software product line. In particular, Connector-VP is used to support choices of different handlers depending on the set of selected features. Thus it realizes the binding between the normal behaviour and the selected exception handler.
@InProceedings{WEH12p62,
author = {Bruno de A. Iizuka and Amanda S. Nascimento and Leonardo P. Tizzei and Cecília M. F. Rubira},
title = {Supporting the Evolution of Exception Handling in Component-Based Product Line Architecture},
booktitle = {Proc.\ WEH},
publisher = {IEEE},
pages = {62--64},
doi = {},
year = {2012},
}
WEH '12: "Modular Fault Handling in ..."
Modular Fault Handling in a Network-Transparent Programming Language
Géry Debongnie, Raphäel Collet, Sébastien Doeraene, and Peter Van Roy
(Université Catholique de Louvain, Belgium)
A programming language is network-transparent if the same program code executes with the same results, whether it is run in a centralized or distributed setting, provided there is no partial failure. The Erlang programming language is network-transparent and handle failures by message passing. We propose in this paper a generalization of the Erlang failure handling model which can be used for more expressive network-transparent languages.
The new design introduces two concepts: entity fault states and fault streams. The failure of an entity is modeled in the system as a language entity, and is visible to the programmer via its corresponding fault stream. We also describe an implementation in Mozart 1.4.0. Evaluation shows that this model incurs a slight overhead in performance, but yields much more modular program code.
@InProceedings{WEH12p18,
author = {Géry Debongnie and Raphäel Collet and Sébastien Doeraene and Peter Van Roy},
title = {Modular Fault Handling in a Network-Transparent Programming Language},
booktitle = {Proc.\ WEH},
publisher = {IEEE},
pages = {18--21},
doi = {},
year = {2012},
}
WEH '12: "Making Exceptions on Exception ..."
Making Exceptions on Exception Handling
Tao Xie and Suresh Thummalapenta
(North Carolina State University, USA; IBM Research, India)
The exception-handling mechanism has been widely adopted to deal with exception conditions that may arise during program executions. To produce high-quality programs, developers are expected to handle these exception conditions and take necessary recovery or resource-releasing actions. Failing to handle these exception conditions can lead to not only performance degradation, but also critical issues. Developers can write formal specifications to capture expected exception-handling behavior, and then apply tools to automatically analyze program code for detecting specification violations. However, in practice, developers rarely write formal specifications. To address this issue, mining techniques have been used to mine common exception-handling behavior out of program code. In this paper, we discuss challenges and achievements in precisely specifying and mining formal exception-handling specifications, as tackled by our previous work. Our key insight is that expected exception-handling behavior may be "conditional" or may need to accommodate "exceptional" cases.
@InProceedings{WEH12p1,
author = {Tao Xie and Suresh Thummalapenta},
title = {Making Exceptions on Exception Handling},
booktitle = {Proc.\ WEH},
publisher = {IEEE},
pages = {1--3},
doi = {},
year = {2012},
}
WEH '12: "The Role of Context in Exception-Driven ..."
The Role of Context in Exception-Driven Rework
Xiang Zhao, Barbara Staudt Lerner, and Leon J. Osterweil
(University of Massachusetts at Amherst, USA; Mount Holyoke College, USA)
Exception-driven rework occurs commonly in software development. In this paper, we describe a simple refactoring process, showing the use of the exception-driven rework exception handling pattern within it. We also discuss the important role that context plays in supporting the user during rework in helping the user keep track of the tasks being worked on and to facilitate resumption of normal activities upon completion of the exception handling work. The example process is specified in the Little-JIL process definition language. The use of context information in supporting the user is illustrated using a Data Derivation Graph (DDG), a graph that is automatically generated to document the ways in which artifact values are evolved during execution of a Little-JIL process.
@InProceedings{WEH12p41,
author = {Xiang Zhao and Barbara Staudt Lerner and Leon J. Osterweil},
title = {The Role of Context in Exception-Driven Rework},
booktitle = {Proc.\ WEH},
publisher = {IEEE},
pages = {41--45},
doi = {},
year = {2012},
}