Thesis submitted to the UNIVERSITY OF COIMBRA for the partial fulfillment of the requirements for the degree of Doctor of Philosophy in Informatics Engineering A Transactional Model For Automatic Exception Handling Bruno Miguel Brás Cabral Under supervision of Prof. Paulo Jorge Pimenta Marques Dep. de Engenharia Informática Universidade de Coimbra, Portugal Departamento de Engenharia Informática Faculdade de Ciências e Tecnologia Universidade de Coimbra Julho 2009 Departamento de Engenharia Informática Faculdade de Ciências e Tecnologia Universidade de Coimbra ISBN 978-989-96001-1-9 Coimbra – Portugal, Julho 2009 This investigation was partially supported by the Portuguese Research Agency – FCT, through a scholarship (SFRH/BD/12549/2003), by CISUC (R&D Unit 326/97), by POCI 2010, and by the European Social Fund To my lovely wife 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 propose a new model that automates the handling of exceptions by the runtime platform. The Automatic Exception Handling (AEH) model frees the programmer from having to write exception handling code and, at the same time, successfully increases the resilience of programs to abnormal situations. The case for automatic exception handling is that, for the majority of situations, benign recovery blocks of code should be part of the runtime platform and should be automatically executed when exceptions are raised. By doing so, the programmer is freed from the “burden” of writing exception handling code for a large number of situations. The proposed model is influenced by three fundamental concepts: Exception Handling; Software Transactional Memory (STM); and Recovery Blocks. We incorporate many concepts from traditional exception handling models in order to keep the essential features already available. But, in broader terms, we allow the user to define handler-free try blocks, while, at the same time, we set a transactional environment for the execution of these blocks and system-defined recovery blocks. Transactions are essential to our model since they provide for atomicity during the execution of protected code blocks and multiple recovery actions. Furthermore, they provide a simple and transparent way of eliminating the effects of failed recovery blocks executions. Our model guarantees that there are no collateral effects arising from the execution of multiple recovery blocks, when it is necessary to execute several of these blocks in order to handle an exception that is repetitively being raised inside a protected block. On the other hand, not all recovery has to be done automatically. The programmer may still deal with a situation on his own, if he or she wishes to do so. We conclude this thesis by describing and testing an implementation of the proposed model. The results of our experiments are very promising. We obtained a substantial decrease on the amount of exception handling that has to be coded (less 30%), the reliability of programs was improved, and the performance penalty was negligible. Moreover, we were able to propose recovery actions for more than 60% of the exception types we analyzed. We show that the automatic exception handling model: a) can be implemented and incorporated onto existent platforms; b) is easily and almost transparently integrated with object-oriented languages; c) is effective on reducing the amount of exception handling code that programmers have to produce; d) has the xi potential to avoid some programming bad practices in terms of reliability and improve the quality of code; e) can reduce development time; and, f) effectively increases the resilience of a system in the presence of errors. Resumo Os primeiros mecanismos de detecção e tratamento de excepções surgiram há quatro décadas. Curiosamente, apesar dos mecanismos actuais não serem muito diferentes dos primeiros modelos, a grande maioria das linguagens de programação modernas confia nestes para lidar com erros e situações anormais. As excepções apresentam múltiplas vantagens quando comparadas com outros mecanismos de detecção e tratamento de erros, como por exemplo, a utilização de códigos de erro e variáveis de estado globais. As excepções eliminam o problema dos semi-predicados, caracterizado por funções que mesmo executando incorrectamente devolvem um valor válido, impossibilitando assim a detecção do problema. O mecanismo de excepções dá ao programador os meios para comunicar e detectar a ocorrência de situações anormais, permite a definição de estratégias de recuperação mais elaboradas (com base na informação existente nos objectos que representam excepções), e permite ao programador lidar com situações anormais de uma forma civilizada. No entanto, e apesar das reconhecidas qualidades do mecanismo na detecção e tratamento de situações anormais, os programadores não estão a utilizar os mecanismos de tratamento de excepções como ferramentas para recuperar o estado dos programas após a ocorrência de um de erro. Na maioria dos casos, quando ocorre um erro, as excepções são silenciadas ou utilizadas apenas para terminar o programa de uma forma ordenada. Neste trabalho, mostramos que as estratégias para tratamento de excepções em sistemas não críticos não existem ou servem apenas o propósito final de manter registo dos problemas para posterior análise (depuração ou “debugging”.) Os programadores dedicam pouco tempo a tentar compreender as excepções, a sua origem e a planear métodos de recuperação. Como resultado, a percentagem de código nestas aplicações exclusivamente dedicado ao tratamento de excepções é muito reduzida. Este facto é inesperado se considerarmos que: a) até mesmo operações simples, como aceder a um ficheiro em disco ou executar uma pesquisa numa base de dados, podem originar um grande número de excepções; b) o mesmo tipo de excepção pode requerer diferentes tratamentos e estes podem variar com o momento ou localização do evento anormal; c) o código para tratamento de uma excepção pode ser tão ou ainda mais complexo que o código que originou a excepção; d) em algumas linguagens de programação (e.g., Java) o tratamento de excepções ou a declaração da sua existência é obrigatório. xiii Este comportamento negligente, por parte dos programadores, parece evidenciar que os mecanismos de tratamento de excepções actuais não se adequam ao perfil dos seus utilizadores. Os programadores consideram a escrita de código de tratamento de excepções uma tarefa complexa, ineficiente e pouco atraente. Esta situação é ainda mais preocupante, tendo em conta que, normalmente, os projectistas de linguagens