Tratamento de erros - qual dos antipadrões você usa?

Que atire a primeira pedra quem nunca usou uma dessas… eu mesmo, hoje trato as exceptions com carinho. Não porque as ame, mas é porque cansei de apanhar. :lol:

O mais bizarro que eu vejo em muitos lugares é esconder a exception:

try { doAnything(); catch(Exception e) { e.printStackTrance(); }

E em um sistema que herdei tinha em quase todo lugar isso:

try { doAnything(); catch(Exception e) { throw new QualquerCoisaException("Ocorreu um erro, tente mais tarde"); }

Sim, tinha a mensagem “tente mais tarde”, hahahaha.

A que eu faço de vez, principalmente em códigos temporário é enjaular em uma RuntimeException:

try { doAnything(); catch(Exception e) { throw new RuntimeException(e); }

E outra que eu faço, porém comentando o motivo, é de fazer catch and ignore. Algumas vezes você precisa fazer algo, mas se der erro você pode seguir o baile sem maiores problemas. Algo do tipo, excluir um arquivo, e se der erro pode seguir o código sem se preocupar com isso. Porém nesses casos penso que é necessário documentar.

Você pode ignorar exceptions, desde que esse seja o tratamento correto da exception. Ou seja, você parou, analisou, e verificou que aquilo realmente pode acontecer, mas não tem problema.

Eu sempre penso assim, se o cara tá com preguiça de escrever código ou tá com o prazo completa e totalmente estourado, e não quer fazer um tratamento de excessão sério, declarar seus métodos lançando Exception (ao invés de uma excessão mais restrita e que faça mais sentido) é molecagem.

Se é assim, lança logo um Throwable e seja feliz!!

Aliás, o Eduardo Guerra escreveu um artigo muito bom na revista MundoJa… opa, MundoJ (:P), na mesma linha desse artigo apresentado aqui, chamado “Os 7 habitos das excessões altamente eficases”. Foi na MundoJota número 36.

Logo que eu aprendi que existiam Exceptions, eu cheguei a fazer controle de fluxo (argh) com eles. hehe

Acho que isso é anti-pattern até dentro da POG. :lol:

Falou…

Opa,

atualmente eu também prefiro lançar as exceptions para serem tratadas em uma camada mais alta... ao invés de tratá-las em todos os lugares (em algum lugar eu li que tratamento de erro é considerado um tema transversal - da mesma forma que log - e que se espalha rapidamente por toda parte do código).

Ao longo do tempo, ganhei alguns maus habitos, entre eles de criar algumas classes utilitárias para os famosos catch vazios, tais como:

public final class FileUtils {

    public static void close(java.io.Writer out) {
        if (out != null) {
            try {
                out.close();
            } catch (IOException ex) {
                // nothing ...
            }
        }
    }

    public static void close(java.io.InputStream ins) {
        if (ins != null) {
            try {
                ins.close();
            } catch (IOException ex) {
                // nothing ...
            }
        }
    }
//...


public final class JDBCUtils {

    private JDBCUtils() {
    }

    public static void close(java.sql.Connection conn) {
        if (conn != null) {
            try {
                conn.close();
            } catch (SQLException ex) {
                // nada a fazer
            }
        }
    }

    public static void close(java.sql.PreparedStatement ps) {
        if (ps != null) {
            try {
                ps.close();
            } catch (SQLException ex) {
                // nada a fazer
            }
        }
    }

    public static void close(Statement cmd) {
        if (cmd != null) {
            try {
                cmd.close();
            } catch (SQLException ex) {
                // nada a fazer
            }
        }
    }

Isso foi uma consequência do uso do findbugs entre outros validadores ([url]http://leepoint.net/notes-java/tools/checkers.html[/url]).

fw

Para quem está fora de um servidor web, é bom conhecer o último recurso que o JDK usa antes de estourar com uma exceção. Toda thread tem associada a ela um UncaughtExceptionHandler.
Ele é chamado antes da exceção ser impressa.

Se nenhuma thread registrar esse cara, quem é chamado é o DefaultUncaughtExceptionHandler. Ele é quem faz a impressão da exception no console.

Você pode usar o método: Thread.setUncaughtExceptionHandler para definir um handler por thread. E pode usa o método estático
Thread.setDefaultUncaughtExceptionHandler para sobrescrever o comportamento padrão.

Isso aí é uma maravilha. Usando isso, você nunca mais deixará de logar aquela RuntimeException inesperada. Sem falar que você também irá dar preferência em transformar CheckedExceptions em RuntimeExceptions, uma vez que a partir dái vc ganha o log de graça. A classe utilitária do Dieval só trocaria os

catch(Exception e) {}

por

catch (Exception e) { throw new RuntimeException(e); }