Developing robust software is a challenging, yet essential, task. A robust program has to be able to detect and recover from a variety of faults such as the temporary disconnection of communication links, resource exhaustion, or memory corruption. Ideally, robust software will tolerate runtime errors without a substantial increase in the code complexity. Indeed, more complex code would augment the probability of design and coding faults and consequently decrease the robustness of the application. Of course, code complexity and robustness are not antonymous if one can avoid or remove design and coding faults in the error handling code.

Language-level exception handling mechanisms allow programmers to handle errors with only one test per block of code. In programming languages without exceptions, such as C, programmers have to check for error return codes after each function call. The use of exception handling mechanisms can thus simplify the development of robust programs. Unfortunately, exception handling is no panacea. First, it is difficult to make concise: a large percentage of an application’s code is dedicated to exception handling because it needs to take into account all the possible causes of errors and subsequently perform various recovery actions. Second, it is difficult to make right: although the use of exceptions simplifies the detection of failures, the elegance of language-level exception handling mechanisms might lead to neglecting recovery issues and produce buggy code. Notably, the premature exit of a method due to an exception might leave an object in an inconsistent state because it does not guarantee atomicity, i.e., "all-or-nothing" semantics. If this inconsistency is not resolved in the error handling code, it might prevent a later recovery, and thus decrease the robustness of the program. Other sources of problem include nested exceptions and concurrency.

This project proposal is based our belief that atomic block constructs, as provided by software transactional memory, provide effective mechanisms to implement concise and correct exception handling code. They take care of rolling back partial effects on the application state between the beginning of a method execution and the throwing of an exception when necessary, thus freeing the programmer from writing complex and error-prone recovery code. Optional compensations actions can be added to take care of the "external" effects of the partial execution of the atomic block.