Artigo Engenharia de Software 23 - Levantando Exceções no Desenvolvimento de Software

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (0)  (0)

Esse artigo trata da Utilização da FCL – Framework Class Library, para tratar exceções levantadas durante o desenvolvimento de aplicações com C#.

Esse artigo faz parte da revista Engenharia de Software 23 edição especial. Clique aqui para ler todos os artigos desta edição



Desenvolvimento

Levantando Exceções no Desenvolvimento de Software

Uma Abordagem Prática

De que trata o artigo:

Utilização da FCL – Framework Class Library, para tratar exceções levantadas durante o desenvolvimento de aplicações com C#. Uma abordagem prática será utilizada para ilustrar essa abordagem.

 

Para que serve:

Para apresentar os tipos de erros que podem surgir na execução de um programa, e auxiliar os desenvolvedores na tarefa de tratá-los, evitando problemas na entrega da aplicação aos seus clientes.

 

Em que situação o tema é útil:

O tema se torna fundamental, no ponto de vista de uma empresa com uma política de testes, a partir do momento que ela esteja tendo altos gastos com testes de software, para identificar potenciais problemas não previstos pelos desenvolvedores. Em empresas sem uma política de testes, este artigo pode ajudar desenvolvedores a identificar e prevenir possíveis falhas no produto final, evitando gastos com manutenção.

 

É fato que todo desenvolvedor, independente da plataforma, também é usuário de várias aplicações, muitas das vezes desenvolvidas por outras pessoas. No nosso dia a dia, como usuários de sistemas, nos deparamos com vários softwares de diversos fabricantes, e por sermos desenvolvedores logo pensamos: eu teria desenvolvido isso de outra forma. A análise crítica está presente em todos os seres humanos, e não seria diferente com os desenvolvedores de software. Quando você se depara com um software que foi modelado de uma forma diferente da que você faria apenas, tudo bem. O problema é quando você vai usá-lo e percebe que o desenvolvedor não fez uma validação dos campos de forma correta, e na mesma hora você repara que determinados dados inválidos levantam exceções que não foram tratadas, logo o sistema falha. Mesmo estando na posição de usuário, é frustrante.

Nesse momento, a vontade é de entrar no código fonte e resolver o problema mas, rapidamente percebe que não tem acesso a ele. Não foi você quem o fez. Sensação semelhante acontece com os outros usuários, que não possuem conhecimentos sobre desenvolvimento, aliás, sequer sabem o que é código fonte. Neste momento, as intenções são diferentes. Ao invés de quererem entrar no código fonte e resolver o problema, eles apenas desistem de usar o software, ou perdem a confiança no produto. É hora da empresa que desenvolveu a solução começar a jogar dinheiro pelo ralo com manutenção para resolver esse problema.

A criação de uma solução modelada de acordo com as necessidades do cliente possui várias etapas, entre levantamento de requisitos, análise, desenvolvimento e testes. Por exemplo, no momento que estamos criando um método que receba dados por parâmetro fornecidos pelo usuário na interface, e retorne um valor, devemos ter em mente que o método aceitará apenas determinados tipos de dados, os que forem necessários para ele realizar a sua função e retornar o resultado. Se o desenvolvedor não ficar atento a esses detalhes, ele corre o risco de permitir que o usuário forneça dados que não são os esperados pelo método. Nesta situação, o software que está sendo desenvolvido vai para a equipe de testes da empresa, onde estas falhas são identificadas, fazendo com que o software volte para o desenvolvedor, gerando um atraso significativo no cronograma do projeto.

Todo esse processo de desenvolvimento de uma aplicação deve ser bem monitorado, para evitar que o produto final esteja sujeito a falhas. Cabe ao desenvolvedor conhecer os tipos de erros e a forma de solucioná-los para evitar problemas com manutenção e testes desnecessários.

Neste artigo vamos analisar os tipos de erros e como evitá-los. Vamos falar também sobre exceções que podem ser levantadas em tempo de execução e mostrar como o desenvolvedor pode identificá-las e se prevenir contra falhas futuras. Para isso, falaremos sobre as estruturas que auxiliam neste processo, como os manipuladores try/catch e finally, além da utilização da FCL – Framework Class Library que, através de exceptions, formam um conjunto moderno e rico de recursos para aumentar a produtividade do desenvolvedor. Todos os recursos que serão apresentados servirão para que a etapa de desenvolvimento seja concluída com êxito, reduzindo o gasto com a etapa de testes ou diminuindo gastos com manutenção do produto.

Cada uma das técnicas que serão abordadas fazem parte de um conjunto de boas práticas no desenvolvimento de aplicações. Através dos exemplos práticos, o desenvolvedor será capaz de entender o que é uma exceção, como são levantadas e porque elas ocorrem. Identificará possíveis pontos de ocorrência e como tratá-las da melhor forma, proporcionando conforto e segurança para os usuários, permitindo que os mesmos tenham informações corretas do que aconteceu e, sendo assim, possam prosseguir na tarefa, sem perder a confiança no software e no resultado obtido.

Conhecendo os tipos de erros

Os Erros de Sintaxe são os causados por alguma declaração inválida, bem como erros na declaração de algumas estruturas, variáveis e até mesmo pela falta de um simples, mas importante, ponto e vírgula.

A Figura 1 mostra um erro simples de sintaxe, causado por não haver no laço for a declaração de uma variável contadora, mas existe o incremento da variável. É comum, no momento que estamos criando um código, esquecermos de detalhes simples. No caso da Figura 1, ocorre um erro de sintaxe ao compilar, como é demonstrado.

Figura 1. Erro de sintaxe.

Os Erros de Runtime são os que ocorrem durante a execução da aplicação, devido a algum dado de entrada inválido, ou um comportamento inesperado qualquer. Tudo que foge ao fluxo principal da aplicação, e que não há tratamento previsto, gera erros em tempo de execução.

Na Figura 2 temos a representação de um fluxo principal, onde temos início e fim. O início representa o começo da ação como, por exemplo, o momento que o usuário vai se cadastrar em um sistema. O final do fluxo principal é o cadastro efetuado com sucesso (Programa termina com êxito). Já o fluxo alternativo é um caminho diferente que se pode tomar, mas que o resultado é o mesmo do fluxo principal. O Fluxo de Exceção Não Tratado representa, por exemplo, a tentativa do usuário de colocar um dado inválido no seu cadastro, como idade negativa, data de nascimento no formato errado, etc. No caso representado pela Figura 2, o sistema levantará uma exceção que o desenvolvedor esqueceu de tratar. Isso fará com que o programa termine com erro. O cadastro não chega a ser concluído e o programa falha.

 

Figura 2. Representação do Fluxo Principal, com possibilidade de ocorrência de Fluxos Alternativos e de Exceção.

Já os Erros de Lógica são os que passam pela compilação e não são detectados em Runtime, mas o resultado esperado não é o obtido. Como exemplo, pode-se ter um método que deveria dar uma saída para uma determinada entrada, mas o que se obtém é um resultado totalmente diferente. Neste caso, uma boa política de testes com implementação de casos de testes poderia resolver o problema. É fundamental que o desenvolvedor esteja ciente da possibilidade de ocorrência destes três tipos de erros, mas apenas os erros de runtime serão abordados dentro do contexto deste artigo.

Como usar Try / Catch e Finally

 Os blocos try/catch permitem ao desenvolvedor criar fluxos principais com a garantia de que, se o bloco try não for executado, uma possível solução exista. O bloco try permite que o desenvolvedor insira código para que, durante a execução do programa, haja uma tentativa de executar aquela ação. A Listagem 1 representa o bloco try.

 

Listagem 1. Sintaxe do bloco try.

1.    try

2.    {

3.      //A execução do programa tentará executar o corpo

do bloco try(tudo entre chaves).

4.    }

Na Listagem 1, linha 1, podemos ver o comando try seguido de duas chaves nas linhas 2 e 4. Se esta tentativa for bem sucedida, o programa terminará com sucesso a ação iniciada. Caso não consiga executar o corpo do bloco try, o compilador levantará uma exceção. Essa exceção deve ser capturada por um bloco catch, que permitirá o tratamento desse erro de runtime, permitindo assim que a execução do programa continue, sem que seja abortado, como mostra a Listagem 2.

 

Listagem 2"

A exibição deste artigo foi interrompida :(
Este post está disponível para assinantes MVP

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?