Tratamento idiomático de erros e exceções em Kotlin

Nesse texto, nosso desenvolvedor Android Pablo Hildo apresenta três ferramentas do Kotlin (linguagem de programação para Android) para realizar tratamento de erros e exceções. Elas possibilitam usar melhor os recursos do Kotlin e da JVM (Java Virtual Machine), além de garantir a escrita de código cada vez mais legível. Acompanhe!

Desde a versão 1.0, o Kotlin traz em sua especificação três ferramentas para realizar tratamento de erros e exceções de forma idiomática e clara: require, check e assert. Cada uma destas é aplicável em casos diferentes e devem ser utilizadas de acordo com o contexto do tratamento.

Todas elas são particularmente úteis porque oferecem uma subclasse previsível de Exception, como tipo, permitindo o bom uso de recursos já existentes da JVM e evitando a reescrita desnecessária de classes para adequar exceções específicas demais. Isso pode simplificar, por exemplo, o processo de validação.

Require

O require é o mais claro e mais utilizável e serve principalmente para validações. É definido como:

A lazyMessage é opcional.

Você deve chamar o require para checar uma condição, geralmente validando um parâmetro, e jogar uma IllegalArgumentException com uma mensagem específica em seu corpo.

Um exemplo praticável em validação é:

Nesse caso, exigimos que a senha não seja nullOrBlank e passamos a lazyMessage “emptyPasswordMessage”. Exigimos que o tamanho seja precisamente 6 com a lazyMessage “passwordMessage” e que a senha seja igual à confirmação, com a lazyMessage “unmatchedConfirmationMessage”. Se qualquer dessas condições exigidas for falsa, a execução da função para naquele momento e joga a exceção, que pode ser obtida (com a lazyMessage passada) por meio de um try catch:

Isso é extremamente positivo porque evita o tratamento de exceções genéricas, centraliza exceções do tipo em uma classe já existente e garante que o código fique muito legível.

Check

O check exige menos explicação. Ele é exatamente igual ao require, mas joga uma IllegalStateException, então existe em benefício do código conciso, idiomático e legível. Levando em conta o nome da exceção, fica claro que seu objetivo é validar estado. Temos, por exemplo, o caso seguinte:

Nessa situação, o bloco de código posterior a check só será executado se loadingLiveData.value for true. Caso contrário, uma exceção do tipo supracitado é jogada.

Assert

O assert, por sua vez, é mais "de nicho" e se aplica em uma situação bem específica, que geralmente é verificação da validade de parâmetro, costumeiramente em debug local. Exatamente por isso é possível chamar de verificação da validade e não de validação, já que não serve no contexto usual de validação.

Ele joga um AssertionError, que só vai ser jogado de fato caso a flag -ea esteja ativada. Se não estiver, é ignorado no código. Seu uso também difere do usual porque no que diz respeito à JVM: “um Error é uma subclasse de Throwable que indica problemas sérios que uma aplicação razoável não deveria tentar manipular. A maioria desses erros são condições anormais”.

Conclusão

Com a aplicação desses três métodos, é possível utilizar melhor tanto os recursos do Kotlin quanto da JVM, assim como garantir a escrita de código cada vez mais idiomático e legível.

No geral, seu uso é pouco comum e não costuma ser reforçado, mas sua aplicação é visualizada com importância na documentação de outros recursos da linguagem. A manipulação dessas exceções da biblioteca padrão representam um passo adicional na tentativa de homogeneizar cada vez mais o código de projetos.

Gostou? Então siga nossa página no LinkedIn e não perca mais conteúdos como esse!