Tratamento de exceções parte 3 - Discussão sobre a remoção das checked exceptions da linguagem Java

Continuação de tratamento de exceções:
Parte 1 – Um pouco de história
Parte 2 – Mudanças no conceito de uso das exceções

Há muita gente que sonha com um fork do Java redundando em um Java mais enxuto, com as APIs limpas de deprecateds e também mais poderoso com a inclusão de algumas facilidades que são difíceis de adicionar ao Java com a atual arquitetura da JVM. Entre as inclusões sonhadas, algumas estão na Java 7 Wish List do Peter Ahé. Juntando os desejos dele com mais alguns outros, sem pretensão de esgotar o assunto, podemos fazer uma lista de facilidades tais como real closures, improved type inference, continuations, tail recursion optimization e até mesmo o assunto desta trilogia que são modificações no tratamento das exceções.

Antes que alguém reclame de me ver escrevendo sobre fork do Java, lembro que a quebra de compatibilidade já aconteceu antes. O Swing no Java 2 quebrou as pernas do Java 1.1.6 baseado em AWT e o novo tratamento do foco no Java 1.4 impediu a migração de alguns sistemas feitos com Java 1.3, inclusive um em que eu trabalhava. Então o tal famoso argumento de que o Java sempre é compatível com si mesmo não é muito verdadeiro. Mas vou deixar este assunto para outra rodada de choppe e vou me ater às questões que me propus levantar sobre o tratamento de exceções.

No ultimo dia 26 de maio, o Neal Gafter em seu blog, em resposta ao colega seu no Google Matt Shulman, abordou a questão de remover as checked exceptions da linguagem Java.

Ele termina com uma pergunta:

“This isn't a question I had thought much about. I believe the language could be simplified by treating all exception types as unchecked without breaking existing programs. This could also result in a simplification of future language extensions and APIs. But would the language and platform be better off without checked exceptions?”

Isto é claro que ele suscitou muita polêmica. Li os 55 comentários e sem revelar ainda minha posição, vou resumir aqui alguns favoráveis às mudanças:

Stefan Schulz said...

I think that removing checked exceptions would be a feature and a benefit.

Matthias Ernst said...

Number one on my list!

Bob said...

Count me in.

Christian Plesner Hansen said...

I ran my own little crusade against checked exceptions a while back. I opened an RFE (#6376696)

Peter von der Ahé

I don't think it would work to make it a compiler option (which is why I was in favor of closing RFE 6376696). However, turning checked exception compile-time errors into compile-time warnings makes a lot of sense to me.

Tim O'Brien said... (autor de Jakarta commons Cookbook e Maven, a Developer Notebook)

I think we need an annotation that would allow us to automate the wrapping of checked exceptions with Runtime.

Não vou listar muitos comentários a favor da manutenção das checked exceptions. Somente listo 2, sendo que o segundo me chamou muita atenção:

Cedric said...

Count me firmly on the side of people who find checked exceptions very important to build API's on big code bases. Sure, they can be misused, but unchecked exceptions are being overused in a lot of places as well.

When I use a method from a library, I want to rely on the compiler to tell me what can go wrong, not on the documentation.

Edson said...

We develop systems using Java and .NET.
We deal with checked exceptions encapsulating them in a framework exception (ugly but documented); but exceptions in .NET are totally undocumented (the Microsoft API does not document all possible exceptions, neither our programmers) and we have very big headaches with unexpected exceptions found in production phase.
We desperately need checked exceptions in .NET; don't remove checked exceptions from Java.

Vale a pena acompanhar a discussão toda, inclusive baixar o PDF da apresentação do Marko Van Dooren Combining the robustness of checked exceptions with the flexibility of unchecked exceptions using anchored exception declarations, onde ele aborda o uso de facilidade da linguagem Eiffel para corrigir problemas das checked exceptions.

Não posso deixar de citar a resposta do do Elliotte Rusty Harold em seu próprio blog com veemente defesa das checked exceptions (80 comentários até agora e o Luca que respondeu lá não sou eu).

O que posso concluir depois de ler tanto sobre o tratamento de exceções no Java?

Confesso que são tantas opiniões bem fundamentadas que fiquei confuso. Certamente sou favorável a um fork do Java, mas não para tirar as checked exceptions. Antes disto, acho que precisariam limpar os "deprecateds" para tornar mais enxuto o tal de JRE consumer. E incluir algumas facilidades que andam falando por aí.

Sobre o que fazer com as checked exceptions, gostaria de ver aplicada, em alguns casos, a sugestão do Ahé de fazer com que elas redundem em warnings ao invés de erros de compilação, principalmente nas APIs do tipo JDBC e java.io em que há uso abusivo. Com a ressalva de que se for adotada em todas APIs, dá medo pensar o que um programador relaxado será capaz de fazer em termos de Exception Hidding.

Pelo medo que descrevi na última frase, acho boa a sugestão do Tim O’Brien de criar uma anotação para facilitar o empacotamento automático das exceções checkeds em uncheckeds. Uma anotação do tipo da @ApplicationException do EJB 3.0 para todo o Java SE também parece interessante.

Espero pelo menos ter chamado a atenção para a importância de discutir o assunto dentro do seu projeto para não ser vítima futura da ira do help desk.