[quote=Rubem Azenha][quote=peczenyj]
Ok, como vc lidaria se SQLException fosse unchecked?
[/quote]
SQLException é um típico caso em que a API não foi bem projetada. Erros como SQLException, HibernateException, IOException, e etc são erros que não tem como ser remediado e geralmente o usuário do sistema não tem controle sobre a situação que gerou o erro, diferente de DataDeVencimentoInvalidaException ou DataSelecionaEhDiaUtilException (nome horrivel, eu admito).
[/quote]
Remediar o problema não tem nada a haver com ser verificada ou não. Não é porque a exceção é verificada que significa que vc pode resolver o problemas. E também não é verdade em exceções não-verificadas.
A diferença entre os dois tipos é conceptual, logo não faz sentido discutir se seria possivel usar java apenas com exceções não-verificadas. É possivel. Tanto é possivel que exceções verificadas só existem em java. Em outras linguagens ninguem sabe o que é isso.
Exceções verificadas são uteis porque obrigam o caller ( quem chama o método) a lidar ( handle, manipular) com a exceção explicitamente. Ou seja, o programador não tem como não saber que ali ha o lançamento de uma exceção.
Isto é particularmente util quando vc está criando frameworks e /ou API de camada. Quando o caller invoca a camada /framework ele perde o controlo. Nesse caso a camada abaixo tem que vigiar que é bem usada. Tal como um método verifica se argumentos não são nulos e estão dentro do esperado, também o mesmo tem que ser feito para exceções. Este tipo de API tem que forçar o caller a lidar com a exceção de forma que lidar com a exceção faz parte do contrato. É chato é, mas é util ? sim. muito. Não tem como vc se esquecer de lidar com a exceção.
Agora, lidar e resolver são coisas diferentes. O caller pode não saber resolver o problema. Nesse caso ele passará a exceção adiante. Mas agora ele é livre de dar tratamento À exceção. Por exemplo, encapsulando-a numa exceção não-verificada.
As API SQL , IO , Threads e Reflection não são mal projetadas. Isso é um mito levantado e alimentado por quem não sabe trabalhar com exceções. Elas usam exceções verificadas porque são API que ao serem chamadas o programador perde o controlo do que acontece ( aka, são chamadas “nativas” ).
As exceções do Hibernate ou do EJB poderiam não ser verificadas. Ai éuma decisão de design, mas não podemos censurar a escolha de usar exceções verificadas só porque temos preguiça de lidar com elas.
Na realidade , porque a maioria dos programadores não divide o programa em camadas , têm que lidar com exceções veirifcadas em todo o lugar da aplicação ( tipo tratar um SQLException dentro de um component siwing). Esse é que é o problema e não as exceções serem verificadas. Se encapsular o uso de SQL em uma camada, de arquivos em uma camada , de reflectino ,etc… nunca mais vai ter problemas com exceções verificadas.
As exceções verificadas são essenciais para um bom design da aplicação, especialmente se ela for um API de uso genérico.
Sem elas é possivel utilizar as mesmas funções da API mas com uma garantia a menos.
Na época em que querem criar anotações @NotNull para verificação automática da passagem de nulos não autorizados, não faz sentido apoiar a ideia de que exceções verificadas são inuteis. Quando mais facilidades existirem para construir bons designs de forma elegante, melhor.
Não digam que a API de SQL foi mal projetada porque usa exceções verificadas que isso pega mal. Ela foi mal projetada sim, mas em outros pontos. Por exemplo, falta de hierarquia de exceções mais fina (embora isso esteja sendo solucionado).
Concordo com o que o Rubem disse. SQLException não é um bom exemplo e não acho que deve ser uma checked exception.