A Filosofia de Tratamento de Erros do Rust

Rust não possui exceções no sentido que Java, Python ou JavaScript têm. Uma função que pode falhar declara isso em seu tipo de retorno, Result<T, E>, e o chamador é estaticamente obrigado a reconhecer essa possibilidade antes de acessar o valor de sucesso. Falha não é um canal de controle de fluxo especial e invisível que se desenrola silenciosamente por camadas de código que nunca optaram por participar - é um valor comum, presente na assinatura do tipo.

Esta é a maior mudança em como Rust trata erros em comparação com a maioria das linguagens populares. Result<T, E> e Option<T> não são recursos nativos da linguagem com sintaxe especial; são enums simples, os mesmos abordados em Modelando Dados com Structs e Enums, combinados exaustivamente como qualquer outro tipo soma. Uma vez que você vê erros como dados, o restante da maquinaria de tratamento de erros do Rust - ?, unwrap, tipos de erro personalizados - se torna uma consequência dessa única decisão, em vez de um monte de recursos separados para memorizar.

Esta página é a âncora conceitual para a seção. Noções Básicas de Tratamento de Erros aborda a sintaxe na prática; esta página explica a filosofia por trás dela.

Resumo

• Falha é representada como um valor comum - Result<T, E> para erros recuperáveis, Option<T> para ausência - verificado exaustivamente pelo compilador em vez de propagado através de desenrolamento de exceção invisível.
• Por que Importa: A assinatura de uma função informa aos chamadores se ela pode falhar antes que leiam uma única linha de sua implementação, e o compilador se recusa a permitir que um Result seja ignorado silenciosamente - eliminando uma categoria inteira de bugs do tipo "esquecemos de tratar o erro".
• Conceitos Chave: Result<T, E>, Option<T>, erros recuperáveis versus irrecuperáveis, panic!, o operador ?, propagação de erros.
• Quando Usar Este Modelo: Ao projetar qualquer função que possa falhar, decidir entre retornar Result e chamar panic!, e ao ler código de biblioteca onde o tipo de erro em uma assinatura é a documentação primária do que pode dar errado.
• Limitações / Compensações: Valores como erros significam que o tratamento de erros é explícito em todos os lugares, o que pode parecer verboso em comparação com try/catch, especialmente antes do operador ? e de bibliotecas como anyhow/thiserror suavizarem a ergonomia.
• Tópicos Relacionados: tipos de dados algébricos, o operador ?, tipos de erro personalizados, panics versus erros recuperáveis.

Fundamentos

Result<T, E> é definido como um enum com duas variantes: Ok(T) para sucesso, carregando o valor, e Err(E) para falha, carregando um valor de erro. Option<T> é seu irmão mais simples, Some(T) ou None, usado quando a ausência de um valor não é em si um erro que vale a pena descrever - uma busca que não encontra nada, em vez de uma busca que falhou.

fn parse_port(input: &str) -> Result<u16, std::num::ParseIntError> {
    input.parse::<u16>()
}

Como Result é um enum comum, você interage com ele da mesma forma que interage com qualquer outro enum: match, if let, ou um de uma grande família de métodos combinadores (.map, .unwrap_or, .and_then). Não há sintaxe try/catch separada para aprender, e nenhuma maneira de um Result ser silenciosamente descartado sem pelo menos ser vinculado a algo - #[must_use] em Result significa que o compilador avisa se você chamar uma função falível e nunca inspecionar o resultado.

Rust divide a falha em duas categorias genuinamente diferentes, e confundir essas categorias é o erro inicial mais comum. Erros recuperáveis são possibilidades esperadas às quais um chamador bem escrito pode responder de forma sensata - um arquivo que não existe, uma requisição de rede que expira, uma entrada que falha ao analisar. Erros irrecuperáveis são bugs: um invariante quebrado, um índice provado fora dos limites, um estado que o programa nunca deveria realmente alcançar. Erros recuperáveis usam Result; erros irrecuperáveis usam panic!, que desenrola (ou aborta, dependendo da configuração) a thread atual em vez de pedir ao chamador para lidar com algo.

Mecânicas e Interações

O operador ? é a peça que torna o tratamento de erros baseado em Result ergonômico em vez de tedioso, e vale a pena ser preciso sobre o que ele realmente faz: nada mais que um retorno antecipado. Colocado após uma expressão do tipo Result, ? desempacota Ok(value) em value e continua, ou, em Err(e), retorna imediatamente da função envolvente com Err(e.into()).

fn read_port(path: &str) -> Result<u16, Box<dyn std::error::Error>> {
    let text = std::fs::read_to_string(path)?; // retorno antecipado em Err
    let port = text.trim().parse::<u16>()?;    // retorno antecipado em Err
    Ok(port)
}

Essa chamada .into() dentro de ? está fazendo um trabalho real: ela permite que uma função retorne um tipo de erro enquanto propaga vários tipos de erro subjacentes diferentes (um erro de I/O, depois um erro de análise, acima), desde que todos eles se convertam no tipo de erro declarado da função via From. É por isso que enums de erro personalizados frequentemente implementam From<std::io::Error> e conversões semelhantes - é o que permite que ? encadeie suavemente através de fontes de erro que, de outra forma, exigiriam encapsulamento manual em cada etapa.

Como ? é apenas açúcar sintático para um retorno antecipado, ele compõe com o fluxo de controle comum exatamente como você esperaria: ele pode aparecer dentro de ramos if, loops, closures retornando Result, em qualquer lugar onde uma expressão do tipo Result possa ser avaliada dentro de uma função cuja própria assinatura de retorno seja compatível. Ele não muda que tipo de tratamento de erro está acontecendo, apenas quanto código repetitivo é necessário para fazê-lo.

panic! funciona através de um mecanismo completamente diferente: ele não retorna nada a um chamador, porque não há um valor Err sendo passado de volta através do sistema de tipos. Por padrão, um panic desenrola a pilha, executando destrutores ao longo do caminho, e então termina a thread; uma configuração de compilação panic = "abort" pula o desenrolamento e termina o processo imediatamente em vez disso. De qualquer forma, panics não são destinados a serem rotineiramente capturados e tratados da maneira que exceções são frequentemente em outras linguagens - catch_unwind existe, mas alcançá-lo como uma estratégia geral de tratamento de erros geralmente sinaliza que a falha deveria ter sido um Result em primeiro lugar.

Considerações Avançadas e Aplicações

Linguagens diferentes resolvem o mesmo problema subjacente - como sinalizar e tratar falhas - com compensações significativamente diferentes.

A distinção biblioteca versus binário molda fortemente essa escolha na prática. Bibliotecas são esperadas para definir enums de erro precisos e frequentemente personalizados (frequentemente com thiserror para reduzir código repetitivo) porque os chamadores precisam distinguir programaticamente os modos de falha. Binários de aplicação mais frequentemente recorrem a um único tipo de erro dinâmico como anyhow::Error, porque no nível superior geralmente apenas se registra o erro ou se sai - a precisão extra de um enum personalizado tem retornos decrescentes quanto mais perto você chega de main.

A dependência do ? em conversões From é também o que impede que o código de tratamento de erros se torne uma parede de chamadas manuais .map_err(...) à medida que os erros cruzam limites de módulo ou crate. Um tipo de erro bem projetado implementa From para cada erro que ele precisa absorver, de modo que a propagação com ? permanece um único caractere em cada local de chamada falível, não importa quantas fontes de erro subjacentes uma função encadeie. É aqui que contexto de erro e backtraces e tipos de erro estruturados ganham seu valor em sistemas maiores: quanto mais longe um erro viaja de sua origem antes de ser registrado, mais esse contexto de origem precisa ser anexado deliberadamente, já que Rust não mantém uma pilha de chamadas implícita através da propagação de Result da maneira que uma exceção não tratada faz.

Código assíncrono muda pouco sobre este modelo conceitualmente - um Result retornado de um async fn é aguardado e combinado exatamente como um síncrono - mas significa que erros de tarefas concorrentes precisam de um caminho explícito de volta para o que quer que esteja coordenando-os, já que não há uma pilha de chamadas compartilhada para um desenrolamento estilo exceção viajar automaticamente.

Concepções Errôneas Comuns

• "Result é basicamente a versão Rust do try/catch." Result é dado fluindo através de valores de retorno normais e correspondência de padrões, não um mecanismo de controle de fluxo separado que desenrola passando por código que nunca optou por participar - cada função intermediária tem que explicitamente propagá-lo ou tratá-lo.
• "? faz algo mágico além de um retorno antecipado." É açúcar sintático para "desempacota Ok, ou retorna Err(e.into()) imediatamente" - a mesma coisa que você poderia escrever manualmente com um match, apenas mais curto.
• "panic! é o mecanismo de exceção do Rust, usado também para falhas esperadas." Panics são para bugs e invariantes quebrados, não para condições que um chamador deveria lidar rotineiramente - recorrer a panic! em uma falha esperada (um arquivo ausente, entrada de usuário inválida) é um sinal de design ruim, não tratamento de erro idiomático.
• "unwrap() é sempre má prática." É totalmente apropriado em testes, protótipos e casos onde a falha representa genuinamente um bug (um invariante que você já provou que é válido) - o problema é usá-lo em erros que um chamador poderia razoavelmente esperar e deveria tratar em vez disso.
• "Você precisa de um tipo de erro personalizado para cada função que pode falhar." Binários simples e pequenas ferramentas geralmente se saem bem com anyhow::Error ou Box<dyn Error>; enums de erro personalizados valem o custo principalmente em bibliotecas onde os chamadores precisam combinar modos de falha específicos.

FAQs

Relacionados

• Noções Básicas de Tratamento de Erros - o guia prático que esta página ancora
• O Operador ? - mecânicas de propagação em profundidade
• panic! vs Erros Recuperáveis - traçando a linha na prática
• Tipos de Erro Personalizados - projetando enums de erro com conversões From
• Modelando Dados com Structs e Enums - os fundamentos de tipo soma em que Result e Option são construídos

Versões da Pilha: Esta página foi escrita para Rust 1.97.0 (edição 2024), Tokio 1.x, Axum 0.8, serde 1.0, sqlx 0.8, clap 4, e Polars 0.46+.