Os mecanismos de tratamento de exceções têm o objetivo de aumentar a robustez e a modularidade do software na medida em que promovem a separação entre o código dedicado ao tratamento de erros e código associado ao fluxo normal de execução do programa. Estes permitem a detecção de erros e a associação de respostas adequadas aos mesmos, através da execução de códigos de recuperação que são geralmente encapsulados em tratadores (do inglês: handlers). A importância dos mecanismos de tratamento de exceção é atestada pelo fato destes fazerem parte da maioria das linguagens de programação mais utilizadas na atualidade: Java, C++ e C#. Na última década a programação orientada a aspectos (POA) vem sendo amplamente utilizada como forma de modularizar interesses que se encontram espalhados nas decomposições primarias de um sistema (e.g., funções, classes, métodos) em uma abstração chamada aspecto. Os aspectos utilizam construções especificas para promover modificações externas nos programas, incluindo comportamentos adicionais em pontos específicos do código. POA vem sido utilizado com o objetivo de aumentar a modularidade do código de tratamento de exceção e de interesses transversais igualmente importantes tais como: persistência, distribuição, segurança, controle de transações e monitoramento. De acordo com alguns estudos empíricos, POA tem sido usado com sucesso com o objetivo de promover o tratamento de erro modular em vários cenários de tratamento de exceções. Porém, é sabido que mecanismos de programação flexíveis (e.g., herança e polimorfismo) podem ter um efeito negativo no tratamento de exceções. Se por um lado os mecanismos de composição POA baseados na inversão de controle podem trazer um novo leque de possibilidades de projeto, promovendo em muitas circunstâncias uma maior estabilidade do projeto (do inglês: design stability), eles podem perder seu valor se ele torna o tratamento de exceções propenso a erros (do inglês: error-prone). Refinamento aspectuais do comportamento do código base, podem por um lado promover a robustez do sistema em situações onde exceções são lançadas ou contribuir para os problemas típicos de tratamento de exceções mal projetados tais como: (i) exceções não capturadas (do inglês: uncaught exceptions); (ii) exceções capturadas por tratadores genéricos (do inglês: exception subsumption) (i.e., exceções capturadas por um tratador cujo argumento é um supertipo da exceção a ser tratada); (iii) e exceções capturadas por tratadores errados (do inglês: unintended handler action). Infelizmente, não existe nenhuma avaliação sistemática dos efeitos positivos e negativos da programação orientada a aspectos na robustez do código de tratamento de exceções. Os trabalhos de pesquisa descritos na literatura têm se limitado a analisar os impactos dos aspectos no fluxo normal de execução do programa. Além disso, a maioria dos estudos empíricos não vai além de discussões sobre os ganhos de modularidade e as ciladas associadas à utilização de aspectos - para o tratamento de exceções e de outros interesses transversais. Por exemplo, estes estudos não levam em consideração as conseqüências inerentes as novas exceções e tratadores que são adicionadas ao código base junto com a nova funcionalidade adicionada pelos aspectos. Esta tese descreve o primeiro estudo sistemático que avalia quantitativamente o impacto da composição aspectual no fluxo excepcional de programas. Este estudo se baseou na utilização de uma ferramenta de análise do fluxo de exceções chamada SAFE (do inglês: Static Analysis for the Flow of Exceptions) desenvolvida ao longo deste trabalho e na inspeção manual do código de tratamento de exceções de um conjunto de sistemas para os quais a versão Java e AspectJ estavam disponíveis. A ferramenta SAFE foi construída com base no framework SOOT para a análise e otimização de bytecode. A partir de uma representação do programa construída a partir do bytecode do código base combinado com os aspectos (do inglê