{"id":2211,"date":"2015-07-06T02:02:33","date_gmt":"2015-07-06T05:02:33","guid":{"rendered":"https:\/\/devkico.itexto.com.br\/?p=2211"},"modified":"2015-07-06T02:02:33","modified_gmt":"2015-07-06T05:02:33","slug":"excecoes-do-java-sao-uteis-talvez-voce-e-que-nao-saiba-usa-las","status":"publish","type":"post","link":"https:\/\/devkico.itexto.com.br\/?p=2211","title":{"rendered":"Exce\u00e7\u00f5es do Java s\u00e3o \u00fateis: talvez voc\u00ea \u00e9 que n\u00e3o saiba us\u00e1-las"},"content":{"rendered":"

Semana passada escrevi<\/a> sobre como os programadores complicam o c\u00f3digo Java. Volto este tema agora para falar um pouco sobre um recurso extremamente \u00fatil da linguagem que, acredito, \u00e9 muito mal compreendido: as exceptions.<\/p>\n

Uma vis\u00e3o hist\u00f3rica<\/h2>\n

Acredito que para dominar uma linguagem de programa\u00e7\u00e3o um dos primeiros passos que devemos tomar \u00e9 buscar entender o que motivou e quais princ\u00edpios guiaram sua cria\u00e7\u00e3o. Uma abordagem hist\u00f3rica cai muito bem neste momento, sendo assim recomendo que voc\u00ea leia o cap\u00edtulo sobre exce\u00e7\u00f5es tal como redigido na especifica\u00e7\u00e3o do Java 1.0, acess\u00edvel neste link<\/a>\u00a0(observem a ironia).<\/p>\n

A leitura desta especifica\u00e7\u00e3o \u00e9\u00a0muito<\/strong> interessante, especialmente quando vemos de forma expl\u00edcita os principais objetivos dos designers na cria\u00e7\u00e3o da linguagem naquele momento:\u00a0prover portabilidade e robustez<\/em>. Ao falarmos de exce\u00e7\u00f5es o que realmente nos interessa \u00e9 o segundo princ\u00edpio. Como esta robustez \u00e9 obtida?<\/p>\n

Antes um pouco de sem\u00e2ntica: uma exception, como o pr\u00f3prio nome j\u00e1 nos diz, denota uma condi\u00e7\u00e3o anormal que ocorre durante o fluxo de execu\u00e7\u00e3o dos nossos programas.<\/p>\n

 <\/p>\n

A vida sem exceptions<\/h3>\n

Muitas linguagens de programa\u00e7\u00e3o simplesmente finalizam a execu\u00e7\u00e3o do software (pense em C ou Pascal) quando algo assim ocorre e n\u00e3o h\u00e1 alguma forma de tratamento do erro padronizada, outra alternativa \u00e9 apenas retornar um c\u00f3digo de erro que pode facilmente ser ignorado pelo programador (pense na fun\u00e7\u00e3o read<\/a><\/strong> do C <\/a>retornando o valor -1, por exemplo).<\/p>\n

Vamos a um exemplo r\u00e1pido usando “pseudo C”. A linguagem possu\u00ed uma fun\u00e7\u00e3o chamada read (mencionada acima) que l\u00ea bytes em uma fonte de dados e a armazena em um buffer. Ela retorna o valor -1 caso algo de errado ocorra, 0 se chegamos ao final do arquivo e um valor positivo nos informando quantos bytes foram lidos. Veja o c\u00f3digo abaixo:<\/p>\n

\r\nchar buffer[128];\r\nread(arquivo, buffer, 128);\r\nprintf("Serei impresso?");\r\n\/\/ opera\u00e7\u00f5es importantes seriam executadas na sequ\u00eancia\r\n<\/pre>\n
Este \u00e9 um c\u00f3digo muito comum: o programador espera que o arquivo\u00a0sempre<\/strong> exista, sendo assim, possu\u00ed a “certeza” de que a sa\u00edda “Serei impresso?” sempre ir\u00e1 ser exposta em seu terminal. Mas nem sempre \u00e9 assim: e se o arquivo imagin\u00e1rio sumir? Nosso ing\u00eanuo programador ir\u00e1 enfrentar problemas pois a execu\u00e7\u00e3o do seu programa terminaria em algum ponto ap\u00f3s esta impress\u00e3o.<\/p>\n
Talvez nosso programador pudesse escrever o c\u00f3digo acima de uma forma diferente tal como no exemplo a seguir:<\/p>\n
\r\nchar buffer[128];\r\nint resultadoLeitura = read(arquivo, buffer, 128);\r\nif (resultadoLeitura < 0) {\r\n\u00a0 \u00a0 \u00a0\/\/ tento corrigir a situa\u00e7\u00e3o aqui\r\n}\r\n<\/pre>\n
\u00c9 uma alternativa, o c\u00f3digo se tornou mais robusto, mas\u00a0sua leitura\u00a0n\u00e3o torna\u00a0claro o que de fato ocorreu<\/strong>\u00a0para termos um erro. O arquivo foi apagado? Seria um problema de permiss\u00e3o? Ainda pior: o c\u00f3digo que motivou a escrita do programa, o fluxo principal (em condi\u00e7\u00f5es ideais de temperatura e press\u00e3o) agora se encontra mesclado ao c\u00f3digo de tratamento de erros.<\/p>\n
Java veio com uma solu\u00e7\u00e3o mais interessante. Visto que nossas classes s\u00e3o uma interface, por que n\u00e3o alertar\u00a0seus clientes a respeito do que pode dar errado e, ainda melhor: for\u00e7a-los a tratar estas situa\u00e7\u00f5es (o problema est\u00e1 neste “for\u00e7a-los”)?<\/p>\n
Pensando como Gosling, Joy e Steele<\/h2>\n
\"java_language_spec\"<\/p>\n
Clareza na escrita<\/h3>\n
Por mais incr\u00edvel que possa parecer a diversos cr\u00edticos atuais da linguagem, naquela \u00e9poca um dos objetivos era ter c\u00f3digo menos verboso. O ideal \u00e9 que o programador pudesse ver o fluxo principal do seu programa de uma forma simples, e o tratamento dos erros isoladamente, tal como no exemplo a seguir:<\/p>\n
\r\nString conteudoArquivo(File arquivo) {\r\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 try {\r\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \/\/ meu fluxo principal entra aqui\r\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 } catch (FileNotFoundException\u00a0ex) {\r\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0\/\/ o que eu fa\u00e7o se o arquivo n\u00e3o existir?\r\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0} catch (EOFException ex) {\r\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \/\/ e se o arquivo chegar ao fim antes do imaginado?\r\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0} catch (IOException ex) {\r\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \/\/ e se for algum outro erro de I\/O que n\u00e3o previ e\r\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0\/\/ n\u00e3o seja como os que mostrei antes?\r\n\u00a0 \u00a0 \u00a0 \u00a0 }\r\n}\r\n<\/pre>\n
\u00c9 interessante como agora voc\u00ea sabe\u00a0o qu\u00ea<\/strong> pode ter dado errado, e consegue diferenciar de forma clara como tratar cada uma daquelas situa\u00e7\u00f5es. Ainda melhor: o que realmente importa, o fluxo principal, est\u00e1 claramente isolado.<\/p>\n
Uma exception \u00e9 na realidade um desvio de fluxo. Talvez voc\u00ea lide com erros do tipo FileNotFound e IOException da mesma forma. Neste caso, como a primeira exception \u00e9 uma subclasse da segunda, basta colocar um \u00fanico bloco catch para esta.<\/p>\n
Exceptions como contrato<\/h3>\n
 <\/p>\n
Mais do que isto, acredito que muitos programadores simplesmente n\u00e3o saibam interpretar o c\u00f3digo que encontram: imagine uma declara\u00e7\u00e3o de m\u00e9todo como a abaixo:<\/p>\n
\r\nvoid processeArquivos(File[] arquivos) throws FileNotFoundException\r\n<\/pre>\n
O m\u00e9todo me diz:<\/p>\n
“Recebo uma lista de arquivos em uma matriz como par\u00e2metro.\u00a0Conseguirei executar meu trabalho quando todos os arquivos forem acess\u00edveis a mim. Se me passar algum deles que n\u00e3o seja, repasso a voc\u00ea, que me chamou, a responsabilidade de lidar com este problema para mim.”<\/p><\/blockquote>\n
O m\u00e9todo, \u00e9 um\u00a0contrato<\/em>, e a exception, uma valida\u00e7\u00e3o de que o mesmo ser\u00e1 cumprido. Se n\u00e3o for o caso, o fluxo dever\u00e1 ser alterado para que o seja ou a responsabilidade para se resolver o problema, repassada a outro objeto (talvez o cliente do cliente).<\/p>\n
Mais do que isto: um contrato v\u00e1lido \u00e9 aquele bem definido. Fica f\u00e1cil perceber quando quem escreveu o c\u00f3digo n\u00e3o tem muita ideia a respeito do que est\u00e1 fazendo. Observe a declara\u00e7\u00e3o de m\u00e9todo abaixo:<\/p>\n
\r\nvoid processeArquivos(File[] arquivos) throws Throwable\r\n<\/pre>\n
O que este m\u00e9todo me diz?<\/p>\n
“Recebo uma lista de arquivos para serem processados, alguma coisa pode dar errado, mas n\u00e3o sei o que.”<\/p><\/blockquote>\n
Temos um meio contrato aqui: apenas sabemos que devemos enviar arquivos para este m\u00e9todo. N\u00e3o sei se todos devem realmente estar acess\u00edveis, apenas os envio.<\/p>\n
Exceptions checadas e n\u00e3o checadas. Pra qu\u00ea?<\/h3>\n
Por que h\u00e1 as tais “checked exceptions” e “unchecked exceptions”? O que diferencia uma de outra? Uma interpreta\u00e7\u00e3o r\u00e1pida seria:<\/p>\n
“Checked exception \u00e9 aquela que \u00e9 uma subclasse de java.lang.Exception e que, se eu disparar no corpo do meu m\u00e9todo, tenho de incluir uma clausula throws. A outra n\u00e3o, eu apenas a disparo l\u00e1 dentro e n\u00e3o aviso ningu\u00e9m a respeito pois \u00e9 uma subclasse de RuntimeException ou Error.”<\/p><\/blockquote>\n
O que n\u00e3o responde quase nada al\u00e9m de expor uma hierarquia de classes incompleta. A resposta \u00e9 mais simples: h\u00e1 erros que s\u00e3o trat\u00e1veis e outros nem tanto. Erros trat\u00e1veis s\u00e3o aqueles que definem um contrato e os clientes conseguem ao menos tentar resolve-los\u00a0quando ocorrem.<\/p>\n
Por exemplo: um arquivo inacess\u00edvel \u00e9 um erro trat\u00e1vel. Se topei com um erro do tipo FileNotFound, talvez seja poss\u00edvel criar um novo arquivo\u00a0para em seguida chamar aquela fun\u00e7\u00e3o ou procedimento novamente.<\/p>\n
Por outro lado, se houver um crash do meu sistema operacional ou meu sistema de arquivos desaparecer, n\u00e3o h\u00e1 muito o que eu possa fazer. \u00c9 um erro de tempo de execu\u00e7\u00e3o (runtime). E a quantidade de problemas deste tipo que podem ocorrer \u00e9 praticamente infinita: seu HD pode pegar fogo, ou seu HD pode ser removido, ou seu sistema operacional pode desaparecer, ou sua rede pode se tornar inacess\u00edvel, ou algu\u00e9m pode desligar o servidor, ou….<\/p>\n
Por que as exce\u00e7\u00f5es do tipo Runtime n\u00e3o s\u00e3o “checked”? Vou pedir para Gosling, Joy e Steele uma for\u00e7a. Veja o que \u00e9 dito na se\u00e7\u00e3o 11.2.2 da especifica\u00e7\u00e3o<\/a>:<\/p>\n
“A informa\u00e7\u00e3o dispon\u00edvel para o compilador Java, e o n\u00edvel de an\u00e1lise que este executa, raramente s\u00e3o \u00a0suficientes para se descobrir\u00a0que erros de tempo de execu\u00e7\u00e3o poder\u00e3o ocorrer, mesmo sendo \u00f3bvio para o programador. Obrigar o programador a declarar todas estas exce\u00e7\u00f5es seria apenas uma tarefa irritante para o desenvolvedor.” (tradu\u00e7\u00e3o minha)<\/p><\/blockquote>\n
\u00c9 interessante tamb\u00e9m ver o que os autores dizem na especifica\u00e7\u00e3o ao nos dizerem por que a outra categoria de erros (java.lang.Error) n\u00e3o s\u00e3o checados<\/a>\u00a0(11.2.1):<\/p>\n
“S\u00e3o problemas que podem ocorrer em in\u00fameros pontos de um programa e cuja solu\u00e7\u00e3o \u00e9 dif\u00edcil ou imposs\u00edvel. Um programa escrito em Java que precisasse lidar com todos estes erros seria uma zona e sem sentido algum” (tradu\u00e7\u00e3o minha)<\/p><\/blockquote>\n
Sendo assim, ao inv\u00e9s de obrigar o desenvolvedor a tratar\u00a0cada um<\/strong> destes problemas, por que n\u00e3o for\u00e7a-lo a lidar apenas com o que pode ser tratado<\/b>? Este \u00e9 um dos principais motivadores: te for\u00e7ar a escrever menos c\u00f3digo e, quem sabe, escrever c\u00f3digo de melhor qualidade.<\/p>\n
Isto n\u00e3o quer dizer que voc\u00ea deva escrever c\u00f3digo como o a seguir:<\/p>\n
\r\ntry {\r\n\u00a0 \u00a0 \/\/ aqui est\u00e1 meu fluxo principal\r\n} catch (Throwable t) {\r\n\u00a0 \u00a0 \/\/ aqui lidarei com todos os problemas poss\u00edveis e imposs\u00edveis\r\n\u00a0 \u00a0 \/\/ dos multiversos\r\n}\r\n<\/pre>\n
Quando escrevemos algo como “catch (Throwable)” estamos com uma das seguintes ideias na cabe\u00e7a:<\/p>\n