Tratamento de exceções

Programação Arquitetura
#1

O tratamento de exceções é um assunto que, para mim, ainda é meio nebuloso.

As vezes vejos sistemas que supostamente tem um tratamento de erro eficiente mas não param de disparar stackTraces no console.

Quando usamos um framework (Struts e afins) a tarefa geralmente fica para o framework. Mas no desenvolvimento de uma aplicação desktop fora de estrutura de um framework, que é muito comum de se ver, é preciso elaborar uma estratégia efetiva.

A estratégia de tratamento de exceções que eu, geralmente, uso consistem em:

-> Criar uma classe especializada de “Exception”;

-> Capturar as exceções;

-> Dispará-las na forma especializada para o sistema e;

-> propagá-las até exibir uma mensagem ao usuário.

Essa estratégia é meio estúpida, mas é a que uso e sem saber se é a melhor.

Alguém tem uma estratégia mais . . . elegante de tratamento de erros.

Qual a estratégia que vcs usam?

#2

Antes só existia java.sql.SQLException e algumas subclasses, como BatchUpdateException, DataTruncation, SQLWarning.

À medida que o Java foi aperfeiçoando seu tratamento de exceções no SQL, apareceram as seguintes subclasses de SQLException:

BatchUpdateException, ClientInfoException, RowSetWarning, SerialException, SQLNonTransientException, SQLRecoverableException, SQLTransientException, SQLWarning, SyncFactoryException, SyncProviderException

e por sua vez as seguintes subclasses de SQLNonTransientException:
SQLDataException, SQLFeatureNotSupportedException, SQLIntegrityConstraintViolationException, SQLInvalidAuthorizationSpecException, SQLNonTransientConnectionException, SQLSyntaxErrorException,

as subclasses de SQLTransientException:
SQLTimeoutException, SQLTransactionRollbackException, SQLTransientConnectionException

Compare SQLException com a exceção de seu framework.

Você pode tratá-la diretamente (é a exceção genérica), ou se os erros puderem ser “refinados”, crie as subclasses.

Não esqueça de setar sempre a causa da exceção, quando for instanciar uma exceção de seu framework.

#3

Certo, isso é o que se faz quando se usa um framework, que normalmente tem uma enginde para tratar os erros especializados.

E numa aplicação desktop? O ideal seria centralizar o tratamento das exceções ou disparar a mensagem para o usuário onde quer que aconteçam a exceções?

O tratamento de exceções é um assunto meio chato.

Até que ponto devemos “traduzir” o erro para o usuário ou tratá-lo efetivamente ?

#4

Você pode ter uma “message box” especial, que mostre uma mensagem amigável e um botãozinho que copie esse conteúdo da mensagem detalhada de erro (com stack trace e outras coisas interessantes) para o clipboard (assim fica fácil de o usuário lhe mandar um email - basta ele fazer um “paste” do texto que foi para o clipboard).

É interessante também fazer uma espécie de log das últimas operações efetuadas, para você ter uma idéia do que o usuário estava fazendo antes de o erro ocorrer. Aí você pode solicitar que esse log seja enviado também (de preferência em formato texto; pode ser ligeiramente codificado, só para não acabar vazando algum dado importante para esse arquivo de log.)

#5