Kotlin Void, Unit, Nothing: Guia Completo 2025

Kotlin - Void vs. Unit vs. Nothing: melhores práticas em 2025

Olá, colegas! Se você já escreveu em Kotlin e se perguntou: "Por que aqui é Unit e não void? E que bicho é esse Nothing?" — você veio ao lugar certo. Este tópico é um verdadeiro sucesso no Stack Overflow com milhares de visualizações, e não é à toa. A confusão entre Void, Unit e Nothing pode confundir até mesmo um desenvolvedor experiente. Em 2025, quando Kotlin ocupa com confiança seu espaço no backend (Ktor, Spring) e Android, entender esses tipos não é apenas um capricho, mas uma necessidade para escrever código limpo, seguro e expressivo.

Neste artigo, não vamos apenas listar definições. Vamos analisá-los com exemplos reais, mostrar onde cada um é adequado e onde é um pecado mortal. Vamos lá!

Resumindo: o que é o quê?

Vamos logo esclarecer as coisas. Esses três tipos resolvem problemas diferentes, embora à primeira vista pareçam semelhantes.

\n
• Void — é uma relíquia do Java. Em Kotlin, existe apenas para compatibilidade. Nunca o use em código Kotlin puro.
\n
• Unit — significa "não retorno nada, mas ainda sou um tipo". Análogo ao void do Java, mas melhor. Usado em 99% dos casos quando uma função não retorna um resultado significativo.
\n
• Nothing — significa "a função nunca será concluída normalmente". Ela要么 lançará uma exceção,要么 entrará em um loop infinito. É uma ferramenta poderosa para controlar o fluxo de execução.
\n

Parece simples? Vamos nos aprofundar.

Void — um estranho no ninho

Se você escreve em Kotlin puro, esqueça Void como um pesadelo. É uma classe do Java (java.lang.Void), que é um wrapper para a palavra-chave void. Ela existe em Kotlin exclusivamente para interagir com código Java.

Exemplo de quando Void pode aparecer no seu projeto:

import java.lang.Void\n\n// Nunca faça isso em Kotlin puro!\nfun doSomething(): Void? {\n    println("Fazendo algo...")\n    return null // É obrigatório retornar null, caso contrário, erro de compilação\n}

Viu esse return null? Essa é a principal desvantagem. Void não pode ter uma instância criada (seu construtor é privado), mas pode ser null. Isso gera confusão e código desnecessário.

Melhor prática 2025: Use Void apenas se estiver sobrescrevendo um método de uma biblioteca Java que exija Void como parâmetro genérico. Por exemplo, em Callable<Void>. Em todos os outros casos, use Unit.

Unit — o rei das funções vazias

Unit é a verdadeira maneira Kotlin de dizer: "A função foi executada, mas o resultado não me interessa". Ao contrário de void, Unit é um tipo completo com um único valor — Unit.

Isso oferece recursos interessantes:

\n
1. Genéricos. Você pode usar Unit em funções genéricas.
\n
2. Funções de ordem superior. Você pode passar uma função que retorna Unit como argumento.
\n
3. Extensões. É possível escrever funções de extensão que retornam Unit.
\n

Exemplo padrão — expressões lambda:

fun executeAction(action: () -> Unit) {\n    println("Preparando para a ação...")\n    action() // Chama a função passada\n    println("Ação executada.")\n}\n\nfun main() {\n    // Lambda que não retorna nada, mas causa um efeito colateral\n    executeAction {\n        println("Olá da lambda!")\n    }\n}

Aqui