Análise do Tratamento de Exceções

6.1.1. Análise dos Fluxos Excepcionais

O trabalho de Sinha et al [SINHA et al, 2004] apresenta uma abordagem de apoio às tarefas de desenvolvimento de software para amenizar os problemas decorrentes dos fluxos de controle implícito, por exemplo, os fluxos excepcionais. Para isso, uma ferramenta foi implementada e realiza uma análise de fluxo excepcional de programas Java a partir da análise do bytecode. Além de identificar os caminhos excecionais (do inglês: exception paths), esta ferramenta identifica um conjunto de anti-patterns

relacionados ao exception path, por exemplo, grande distância entre a sinalização e o tratamento (do inglês: large distance between throw and catch). A análise de fluxo excepcional realizada na nossa abordagem não identifica todo exception path, apenas os pontos de sinalização e tratamento, visto que as abordagens de especificação da política de tratamento de exceções não consideram essas informações.

Fu et al [FU & RYDER, 2007] [FU & RYDER, 2005] propuseram uma ferramenta para análise dos fluxos excepcionais de aplicações Java baseada na análise interprocedural de fluxo de dados (do inglês, dataflow) do framework SOOT. Para eliminar alguns blocos catch inalcançáveis a partir da propagação das exceções correspondentes, os autores implementaram uma análise Reaching Definition [FU et al, 2005] baseando-se em uma análise de points-to [NIELSON et al, 2015]. As análises realizadas incluem os métodos percorridos pelas exceções da sinalização até o tratamento, ou seja, a ferramenta identifica todo exception path. O trabalho de Fu et al em [FU & RYDER, 2007] evolui o trabalho em [FU & RYDER, 2005] permitindo a identifica das cadeias de exceções (do inglês: exception chain). O objetivo das ferramentas propostas é de auxiliar os desenvolvedores na compreensão do tratamento excepcional, principalmente em relação às cadeias de exceções (exception chain). Diferentemente dos trabalhos de Fu et al, nossa ferramenta de análise do fluxo excepcional baseia-se em uma análise interprocedural para construir o call graph a partir da análise 1-CFA [NIELSON et al, 2015] usando o framework WALA. Para identificar a ocorrência de instruções throw dentro dos blocos catch e se as exceções capturadas são parâmetros dessas instruções, uma análise intraprocedural baseada na técnica def-use é executada. Portanto, a nossa abordagem também permite identificar cadeias de exceções a partir de um simples procedimento de rastreamento. Entretanto, o algoritmo def-use usado na análise intraprocedural realizada na nossa abordagem é limitada a um nível do uso da exceção capturada, ou seja, se a exceção capturada e for usada na instanciação de um objeto e1 (primeiro nível de uso), e em seguida, o objeto e1 for usado para instanciar o objeto e2 (segundo nível de uso), que, finalmente, é sinalizado (e.g., throw e2), o algoritmo def-

use implementado não reconhece o uso da exceção capturada e na instrução throw. O trabalho de Bravenboer e Smaragdakis [BRAVENBOER et al, 2009] ressalta que a análise do fluxo excepcional quando ocorre em paralelo a análise de points-to eleva a precisão dos resultados e melhora o desempenho dessa análise do fluxo excepcional. Para a análise dos fluxos excepcionais, o ganho de precisão é inexpressivo, como

divulgado neste trabalho, o principal benefício é a melhora do desempenho em comparação com outras análises dos fluxos excepcionais. A implementação da análise de fluxo excepcional da nossa ferramenta não utiliza análise de points-to, porém a forma como a mesma foi implementada permite que outros algoritmos e ferramentas de análise estática possam ser acopladas de forma a melhorar desempenho da análise dos fluxos excepcionais. Para melhorar o desempenho da nossa análise nos utilizamos de uma cache com os valores dos fluxos excepcionais de partes do código que já foram analisadas (como ilustrado na Seção 7.2).

6.1.2. Análise das Ações de Tratamento

Cabral el at [CABRAL & MARQUES, 2007] analisaram o código responsável pelo tratamento excepcional de 32 sistemas Java e .NET e identificaram que a maioria das ações de tratamento são muito simples, sendo predominante a ação de log. Assim, os autores observaram que os desenvolvedores não realizavam ações de recuperação da condição excepcional o que seria o principal propósito dos mecanismos de tratamento de exceções embutidos nas linguagens de programação. Um estudo similar foi realizado por Coelho et al [COELHO et al, 2008b], porém esta análise teve como foco principal a comparação entre o tratamento de exceções OO e os tratamentos de exceções modularizados em aspectos. Ebert et al [EBERT et al, 2015] realizaram um estudo exploratório no qual compararam as respostas de um survey aplicado a desenvolvedores com a análise de bugs reportados nos repositórios que estavam relacionados ao tratamento de exceções. Barbosa et al [BARBOSA et al, 2014] também executaram um estudo empírico de análise dos repositórios de sistemas de código aberto para identificar bugs reportados que foram causados devido o tratamento inadequado das exceções.

Uma das contribuições desses estudos é a identificação e análise de bugs decorrentes do tratamento inadequado das exceções, o que possibilita a construção de um catálogo dos bugs do tratamento de exceções. Esse catálogo guiaria os desenvolvedores na especificação da política de tratamento de exceções para evitar cenários de possíveis

bugs (bug hazard). Atualmente, os resultados da extração e checagem das regras da

abordagem proposta incluem poucas informações sobre as ações de tratamento. Entretanto, os componentes que implementam a nossa abordagem extraem e armazenam as informações das ações de tratamento. Portanto, a abordagem proposta pode ser extensível a extração e checagem de regras que incluem as ações de tratamento.

6.2. Abordagens de Apoio à Definição e Checagem da Política de Tratamento de