A transactional model for automatic exception handling

Abstract

Exception handling mechanisms have been around for more than 30 years. Although modern exceptions systems are not very different from the early models, the large majority of modern programming languages rely on exception handling constructs for dealing with errors and abnormal situations. Exceptions have several advantages over other error handling mechanisms, such as the return of error codes or the usage of global state flags.Exceptions eliminate, for instance, the semipredicate problem, which occurs when a function fails to execute correctly but returns a valid value, thus leaving the caller unaware that an error occurred. Furthermore, exception mechanisms give the programmer an efficient error notification instrument, allow better recovery strategies based on the rich error data available on the exception objects, and allow the programmer to deal with abnormal situations in a civilized way. Nonetheless, and despite the mechanism's broadly recognized qualities on handling and recovering from errors, on our work we show that programmers are not using exception handling constructs as a recovery mean. Most times, when an error occurs, exceptions are silenced or just used to terminate a program in an orderly fashion, not really to recover. We show that the strategies for dealing with exceptions on non-critical programs are commonly non-existent or serve the final purpose of keeping track of problems for later analysis (debugging). Very little effort is normally spent trying to understand exceptions, their causes, and planning recovery actions. As a result, the amount of code found in these applications that is exclusively dedicated to exception handling is usually reduced. This is an unexpected fact. We would anticipate a much larger chunk of code dedicated to exception handling if we consider that: a) Simple operations, such as accessing a file on disk or sending a query to a database, can raise a large number of different exceptions; b) Each different exception type can have several distinct handling actions that may vary with location and time; c) Code for handling an exception can be as or more complex as the code raising the exception; d) In some programming languages (e.g., Java) it is mandatory to handle exceptions and declare their existence.The unwillingness of software designers to correctly deal with exceptions and follow some well known best-practices for exception handling contributes to the lowering of the quality of programs and their resilience to errors. The premise for our work is that something is not right with current exception handling models: they are not adequate enough for developers. The problem is even more worrisome if we consider that programming X ABSTRACT languages designers often neglect the exception mechanism and look at it more like an add-on for their language instead of a central part. As a consequence, software quality suffers as programmers feel that the task of writing good error handling code is too complex, unattractive and inefficient.In this dissertation we prop...

Automatic recovery from runtime failures

“…Moreover, they assume the applications to be stateless, since they do not offer any mechanism to handle the state after a failure. Cabral et al instead can automatically deploy applications with exception handlers that can deal with general problems (e.g., I/O exceptions) but they still require developers to write the exception handlers for application-specific exceptions [12]. Finally, Harmanci et al propose new Java constructs to execute alternative blocks of code in case of exceptions [29].…”

“…Therefore, more recent techniques attempt to avoid or mask failures without incurring the significant costs of producing fully redundant code. Among them, some address specific problems such as inconsistencies in data structures [4], [5], configuration incompatibilities [6], infinite loops [7], security violations [8], and non-deterministic failures [9], [10], while others are more general but require developers to manually write appropriate patches to address application-specific problems [11], [12].…”

Automatic Workarounds

“…Exception handlers are usually very much application specific. However, several techniques extend basic exception handling mechanisms towards general handler that can work for multiple applications [Cabral and Marques 2011;Chang et al 2013;Harmanci et al 2011]. A similar approach, whereby a rule-based response mechanisms encodes alternative operations executed in response to a failure, has been applied to Web systems [Baresi and Guinea 2011;Modafferi et al 2006;Friedrich et al 2010].…”

Handling exceptions in programs with hidden concurrency: New challenges for old solutions

“…Another alternative would be for the system to automatically handle the most common exceptions [9]. This way the programmer would not have to write EH code itself.…”