4
respostas

Dúvida sobre exception

Tenho uma dúvida, no caso na parte "mãos na massa" foi orientado a utilizar o using visto que a única função do try, catch, finally era verificar se a referência do leitor era nula ou não, porém se ocorrer qualquer exceção o using não vai tratar, ou seja não faz sentido deixar o código somente com o using e remover o resto do código, o meu código apresenta erro por não ter a exceção tratada, gostaria de saber qual o melhor lugar para se colocar um try, catch... Conforme os códigos abaixo se eu deixar a exceção ativa no construtor e chamar o mesmo no programa principal o console vai fechar e gerar uma exceção não tratada... Além disso gostaria de saber se em um programa eu posso usar quantos try catchs eu julgar necessário, se isso é uma má pratica, e se teria alguma dica pra otimizar o uso desse recurso.

            using (LeitorDeArquivo leitor = new LeitorDeArquivo("documento.txt"))
            {
                leitor.LerProximaLinha();
                leitor.LerProximaLinha();
                leitor.LerProximaLinha();
            }
    public LeitorDeArquivo(string arquivo)
    {
        Arquivo = arquivo;

        throw new FileNotFoundException();
        Console.WriteLine("Abrindo arquivo: " + arquivo);
    }
4 respostas

Uma outra dúvida, não consegui imaginar o sentido de usar um try sem ter um catch pra tratar a exceção, poderiam me dar um exemplo de quando isto se torna funcional?

Olá João!

Isso foi realmente para fins didáticos.Penas para mostrar as possibilidades. Isso também entra na parte de aprender refatorar o código.

O using() é a mesma coisa que fazer o try para abrir um arquivo e usar o finally apenas para fechar o arquivo que foi aberto. Essa foi a hora escolhida para mostrar essa funcionalidade.

Quanto ao melhor lugar para pegar uma exceção, vai depender de qual momento é esperada essa exceção. Neste caso faz sentido, pois a exceção faz parte da instanciação do objeto. Caso fosse uma função que recebe um certo parâmetro que você não tem muita certeza se esse parâmetro será atendido, então é interessante colocar o try..catch()..finaly na chamada dessa função. Se precisar de mais de um catch(), pode colocar sem problemas, desde que a exceção mais específica venha antes da mais genérica.

Quanto a linha throw new FileNotFoundException(); sempre que chegar neste ponto irá lançar a exceção. Neste caso é interessante colocar a tentativa de abrir o arquivo dentro de um try e um catch() para FileNotFoundException(). Ao não encontrar o arquivo, você poderá tratar a exceção dentro do catch().

Quanto a última dúvida, o try sempre deve ser acompanhado de um catch() ou um finally (ou dos dois). Sem algum desses dois, realmente não faz sentido colocar o try.

Espero ter ajudado!

Ajudou bastante, só não consigo imaginar um cenário onde eu usaria um try e não colocaria um catch, visto que o propósito do try é tentar fazer algo e o catch tratar caso dê problema, poderia me dar um exemplo onde seria valido ter um try sem um catch e isto seria útil ao código?

João, para a maioria dos casos, é usado o using, pois essa é a função de se usar um try..finally. Se você quiser apenas liberar um recurso, que não implemente o IDisposable.

Mas é claro, o using é um açúcar sintático para o try..finally e essa facilidade é uma convenção da comunidade. Use o try..finally quando sua aplicação quiser liberar um recurso. Mas prefira usar o usingpor ser mais simples.

Um uso bem comum (desde que não esteja usando Entity Framework ou outros) é com banco de dados. Normalmente é possível abrir uma quantidade limitada com o banco de dados e essa conexão é muito custosa para o sistema.

Você pode fazer assim implementando IDisposable:

using(AbreConexao())
{
    // Código com o banco de dados
}

Ou então:

try
{
    AbreConexao();
    // Código com o banco de dados
}
finally
{
    FechaConexao();
}

Bom, no geral é essa a ideia.

Quer mergulhar em tecnologia e aprendizagem?

Receba a newsletter que o nosso CEO escreve pessoalmente, com insights do mercado de trabalho, ciência e desenvolvimento de software