Tratamento de erros no desenvolvimento móvel: o que é, quais técnicas e como organizar

Tratamento de erros no iOS: Do-Catch, Throw, Guard Let

O tratamento de erros em Swift é construído em quatro mecanismos-chave: do-catch, throws, guard let e if-let. Ao contrário de muitas linguagens, Swift não permite exceções não capturadas — cada erro deve ser explicitamente tratado ou declarado via throws. O tratamento de erros é uma habilidade crítica para o desenvolvimento móvel, impactando diretamente a estabilidade da aplicação.

Do-Catch e Throw

do-catch é o bloco padrão para chamar funções marcadas com throws. Dentro de do, uma função é chamada com try, e se ela lançar um erro, o controle passa para catch. Diferentes tipos de erro podem ser tratados via pattern matching. Se um erro não for tratado, ele propaga-se pela pilha (Error Propagation). Para um tratamento eficaz de erros no iOS, use do-catch como mecanismo principal.

Throw é declarado na assinatura da função: func fetchData() throws -> Data. Isso significa que o código chamador deve tratar o erro via try, try? ou try!. try? converte o erro em nil, try! causa uma falha em caso de erro (use apenas se tiver certeza do sucesso). O tratamento de erros via throw é prática obrigatória em Swift.

Optional/Nullable e Guard Let

Guard let é uma construção para saída antecipada de uma função se o valor for nil. Ao contrário de if-let, guard let requer uma saída (return, throw, break) no ramo else. Isso torna o código mais plano e legível — sem blocos if aninhados. Se um optional não pode ser nil — use force unwrap (!), apenas quando absolutamente certo. Numa aplicação móvel, guard let ajuda a evitar falhas ao lidar com valores opcionais.

Optional Chaining (user?.address?.city) e nil-coalescing (??) são açúcar sintático para trabalhar com optionals sem desembrulhar. Na IT Sectr, usamos guard let para validar parâmetros de entrada de API e exigimos que a equipe evite force unwrap sem um comentário explícito. Um manipulador de erros em cada nível protege contra falhas inesperadas.

Tratamento de erros no Android: Try-Catch, Elvis, Sealed Class

Kotlin é a linguagem principal para desenvolvimento Android. Herda try-catch do Java, mas adiciona alternativas mais seguras: operador elvis, require, check e sealed class. O tratamento de erros em Kotlin é construído numa combinação destes mecanismos. Ao contrário do Swift, Kotlin não exige o tratamento de exceções verificadas (todas as exceções são unchecked). Para tratamento de erros em aplicações móveis no Android, use sealed class como padrão principal.

Try-Catch e Operador Elvis

Try-catch em Kotlin funciona como uma expressão — retorna um valor. val result = try { fetchData() } catch (e: Exception) { fallbackValue }. Isso reduz o código. O operador Elvis (?:) é um análogo de nil-coalescing para tipos nullable: val name = user?.name ?: "Guest". Para tratamento de erros em aplicações móveis, try-catch como expressão é a abordagem mais concisa.

Sealed class é uma ferramenta poderosa para modelar estados de sucesso e erro. sealed class NetworkResult { data class Success(val data: T) : NetworkResult(); data class Error(val message: String) : NetworkResult() }. Quando usada numa expressão when, o compilador verifica a exaustividade dos ramos. O tratamento de erros via sealed class garante que nenhum estado fique sem tratamento.

// Sealed class + try-catch — padrão típico para Android
sealed class NetworkResult<out T> {
    data class Success<out T>(val data: T) : NetworkResult<T>()
    data class Error(val message: String) : NetworkResult<Nothing>()
}

fun fetchUser(id: String): NetworkResult<User> {
    return try {
        NetworkResult.Success(api.getUser(id))
    } catch (e: Exception) {
        NetworkResult.Error("Failed: ${e.message}")
    }
}

No exemplo, a sealed class NetworkResult modela dois estados: sucesso com dados e erro com mensagem. A função fetchUser retorna um resultado em qualquer caso, e o código chamador trata ambos os ramos via when. Isso elimina a possibilidade de um erro não tratado. O tratamento de erros via sealed class é o padrão para desenvolvimento Android na IT Sectr.

Tratamento de erros no Kotlin: Result e Either

Result é um tipo integrado do Kotlin para representar o resultado de uma operação que pode falhar. Força o tratamento de sucesso e falha via fold, getOrThrow ou map. Result é útil em cadeias assíncronas (coroutines). O tratamento de erros com Result é um padrão para desenvolvimento móvel em Kotlin.

Result vs Either

Either é um tipo funcional da biblioteca Arrow que permite retornar um valor de um dos dois tipos (Left — erro, Right — sucesso). Ao contrário de Result, Either pode conter qualquer tipo de erro definido pelo utilizador. Para projetos simples, o Result integrado é suficiente; para projetos complexos, use Either do Arrow. A escolha da ferramenta de tratamento de erros depende da complexidade do projeto.

Propagação de erros

Propagação de erros é um mecanismo onde um erro se propaga pela pilha de chamadas até ser tratado. Em Kotlin, isso acontece por padrão (exceções unchecked). Em Swift, aplica-se apenas a funções marcadas com throws. Com Result e Either, os erros não se propagam — permanecem no tipo e devem ser tratados. Isso torna o tratamento de erros em aplicações móveis mais seguro.

A tabela mostra as principais diferenças. iOS exige declaração explícita de erros (throws), tornando o código mais seguro, mas mais verboso. Android depende da disciplina do desenvolvedor. Na IT Sectr, usamos sealed class para Android e throws para iOS — é a melhor prática de ambas as plataformas para tratamento de erros em aplicações móveis.

Crash Reporting: Crashlytics e Sentry

Crash reporting é um sistema de recolha e análise de falhas da aplicação. Crash reporting é uma parte essencial do tratamento de erros em produção. Sem ele, você descobre problemas através dos utilizadores, o que é inaceitável para produção. Duas ferramentas principais: Firebase Crashlytics (gratuito) e Sentry (gratuito para uso básico). Para tratamento de erros em aplicações móveis, implemente sempre crash reporting desde o primeiro lançamento.

Firebase Crashlytics

Crashlytics faz parte do Firebase. Recolhe automaticamente falhas, agrupa-as por pilha de chamadas e mostra o número de utilizadores afetados. Suporta registo de erros não fatais via recordException(). Integração: adicione o SDK ao build.gradle (Android) ou Podfile (iOS). Crashlytics é a melhor ferramenta gratuita para tratamento de erros ao iniciar um projeto.

Sentry

Sentry é um sistema multiplataforma de monitorização de erros. Ao contrário do Crashlytics, o Sentry fornece rastreio detalhado (breadcrumbs), monitorização de desempenho e suporte para React Native. Permite visualizar o estado da aplicação no momento do erro. A IT Sectr recomenda Sentry para projetos que precisam de controlo total sobre o tratamento de erros no desenvolvimento móvel.

Error Boundary no React Native

Error Boundary é um componente React que captura erros JavaScript na árvore de componentes filhos e exibe uma UI de fallback, evitando uma falha completa da aplicação. Error Boundary é um componente chave para tratamento de erros no React Native. Use error boundaries para ecrãs críticos e navegação. O tratamento de erros em aplicações móveis no React Native requer uma configuração adequada de Error Boundary ao nível superior.

Implementação de Error Boundary

Error Boundary é criado via componentDidCatch(error, errorInfo) ou static getDerivedStateFromError(error). Não captura erros em código assíncrono (setTimeout, requestAnimationFrame), renderização do lado do servidor ou erros nativos (Native Modules). Para registo, use o SDK de crash reporting dentro de componentDidCatch. Error Boundary é um manipulador de erros simples mas eficaz para a camada de UI.

Erros fatais vs não fatais

Erro fatal é uma exceção não tratada que causa uma falha da aplicação. Erro não fatal é uma exceção que capturou e tratou, mas indica um problema no código. Erros não fatais são registados via Crashlytics/Sentry e ajudam a encontrar bugs antes de se tornarem fatais. Tanto erros fatais como não fatais requerem tratamento adequado de erros no desenvolvimento móvel.