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 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 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.

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. 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 de programação olham para os mecanismos de tratamento de excepções como um componente periférico ao seu sistema e não como uma parte central. Consequentemente, a qualidade do software irá sofrer. Nesta dissertação propomos um novo modelo de tratamento de excepções que automatiza o tratamento de situações anormais e o torna numa responsabilidade da plataforma de execução. O nosso modelo liberta o programador da tarefa de escrever código para lidar com erros ou situações inesperadas e, simultaneamente, aumenta a resiliência dos programas aos erros. O modelo de Tratamento Automático de Excepções (TAE) proporciona uma forma efectiva de lidar com excepções sem interferir com a produtividade dos programadores. Para um grande número de excepções é possível que a própria plataforma de execução forneça, aquando de uma excepção, blocos de código de recuperação benignos capazes de recuperar o estado de um programa e permitir a continuação da execução. Desta forma, os programadores ficam livres da tarefa de escrever código de tratamento para um grande número de excepções. O modelo proposto tem por base três fontes de influência muito díspares: os modelos de tratamento de excepções existentes; o mecanismo de blocos de recuperação; e o mecanismo de memória transaccional por software. De forma a preservar algumas funcionalidades já existentes, incorporámos no nosso modelo muitos conceitos associados aos mecanismos de tratamento de excepções mais eficientes. No entanto, permitimos que o programador defina blocos try{} sem ter de criar blocos de tratamento associados (e.g., blocos catch ou finally) e, simultaneamente, definimos um ambiente de execução transaccional para esses blocos try e para os blocos de recuperação de excepções automáticos implementados ao nível do sistema. As transacções são essenciais ao nosso modelo, sendo que, garantem a atomicidade da execução dos blocos try{} e dos múltiplos blocos de recuperação. Mais importante ainda, é o facto das transacções permitirem eliminar de uma forma limpa e transparente, os efeitos da execução de blocos de código onde ocorreram excepções. O ambiente de execução transaccional assume uma importância ainda maior quando constatamos que a forma de recuperar de uma excepção, apesar de ser correcta numa XIV RESUMO situação, pode mostrar-se totalmente inadequada noutra, para o mesmo tipo de excepção. Assim, em certas ocasiões, será necessário experimentar diferentes tipos de tratamento antes de o sistema conseguir recuperar da excepção. O nosso modelo assegura que quando é necessário executar mais do que um bloco de recuperação, de forma a eliminar uma excepção reincidente dentro do bloco de código protegido, não irão existir efeitos colaterais da execução dos vários blocos de recuperação ou das várias tentativas de execução do bloco de código protegido. Por outro lado, o tratamento de excepções não tem de ser totalmente automático. O programador pode optar por ser ele a definir o tratamento para uma ocorrência excepcional específica, se assim o preferir. Concluímos esta dissertação com a discussão, teste e validação de uma implementação do modelo proposto. Os nossos testes mostram que é possível obter uma redução substancial na quantidade de código de tratamento de excepções que é necessário escrever (menos 30%). Também é perceptível um aumento assinalável na resiliência aos erros dos programas analisados. Além destas melhorias, foi possível observar que o impacto da utilização do novo modelo na performance dos sistemas estudados pode ser considerado negligenciável. Finalmente, para provar que é exequível a criação de acções para recuperação automática de excepções ao nível do sistema, desenvolvemos um conjunto acções benignas capazes de lidar com mais de 60% dos tipos de excepções analisados. No geral, mostramos que o modelo de tratamento automático de excepções: a) é passível de ser implementado e incorporado em plataformas de execução e desenvolvimento já existentes; b) é facilmente e quase de forma transparente integrável com linguagens de programação orientadas-aos-objectos; c) é eficaz a reduzir a quantidade de código dedicada ao tratamento de excepções que os programadores têm de escrever; d) tem potencial para melhorar a qualidade do código final das aplicações e evitar que o programador “caia” em más práticas de programação no que diz respeito à robustez dos programas; e) pode reduzir os tempos de desenvolvimento; e, por último, f) aumentar globalmente a robustez de um sistema.