Research Papers on Mouldable Failure Handling

 

Stayin' Alert: Moulding Failure and Exceptions to Your Needs

A. Bagge, V. David, K. T. Kalleberg, and M. Haveraaen. Stayin' Alert: Moulding Failure and Exceptions to Your Needs. In Proceedings of the 5th International Conference on Generative Programming and Component Engineering (GPCE'06), Portland, Oregon, October 2006. ACM Press. (draft pdf, publication)

Dealing with failure and exceptional situations is an important but tricky part of programming, especially when reusing existing components. Traditionally, it has been up to the designer of a library to decide whether to use a language's exception mechanism, return values, or other ways to indicate exceptional circumstances. The library user has been bound by this choice, even though it may be inconvenient for a particular use. Furthermore, normal program code is often cluttered with code dealing with exceptional circumstances.

This paper introduces an alert concept which gives a uniform interface to all failure mechanisms. It separates the handling of an exceptional situation from reporting it, and allows for retro-fitting this for existing libraries. For instance, we may easily declare the error codes of the POSIX C library for file handling, and then use the library functions as if C had been extended with an exception mechanism for these functions -- a moulding of failure handling to the user's needs, independently of the library designer's choices.

 

DSAL = library+notation: Program Transformation for Domain-Specific Aspect Languages

A. Bagge, K. T. Kalleberg. DSAL = library+notation: Program Transformation for Domain-Specific Aspect Languages. In Proceedings of the First Domain Specific Aspect Language Workshop (DSAL'06), Portland, Oregon, October 2006. Online publication. (draft pdf)

Domain-specific languages (DSLs) can greatly ease program development compared to general-purpose languages, but the cost of implementing a domain-specific language can be prohibitively high compared to the perceived benefit. This is more pronounced for narrower domains, and perhaps most acute for domain-specific aspect languages (DSALs).

A common technique for implementing a DSL is writing a software library in an existing programming language. Although this does not have the same syntactic appeal and possibilities as a full implementation, it is a technique familiar to most programmers, and it can be done cheaply compared to developing a full DSL compiler. Subsequently, the desired notation may be implemented as a simple syntactic preprocessor. The cross-cutting nature of DSALs, however, makes it difficult to encapsulate these in libraries.

In this paper, we show a technique for implementing a DSAL as a library+notation. We realize this by implementing the library in a program transformation system and the notation as a syntactic extension of the subject language. We discuss our experience with applying this technique to multiple kinds of DSALs.

One of these extensions provide mouldable alert handling -- a flexible and uniform interface to error handling that cleanly separates the handling of exceptional situations from their reporting.

 

Separating Exceptional Concerns

Anya Helene Bagge: Separating exceptional concerns. 5th WEH@ICSE 2012: Zurich, Switzerland; 49-51. (publication)

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.

 

Concrete Error Handling Mechanisms should be Configurable

Tero Hasu: Concrete error handling mechanisms should be configurable. 5th WEH@ICSE 2012: Zurich, Switzerland; 46-48. (publication)

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.