Non-Fatal Error en aplicaciones móviles — esencia, tipos y manejo de errores

Qué es un Non-Fatal Error

Non-Fatal Error — es una excepción o estado de error que no provoca la terminación del proceso. La aplicación sigue funcionando, pero puede estar en un estado incorrecto: no se cargaron los datos, no se envió una solicitud, no se mostró un elemento de la interfaz. El usuario o no nota el error, o ve un mensaje y continúa usando la aplicación.

Características clave

Un error no fatal siempre deja al programa un camino para recuperarse. El manejador de errores puede ofrecer datos alternativos, reintentar la operación o mostrar un marcador de posición en la interfaz. El objetivo principal es evitar un cierre y mantener una experiencia de usuario aceptable. El desarrollador debe prever explícitamente un escenario de recuperación en cada bloque catch.

Rol en la estabilidad de las aplicaciones

Según Instabug 2024, el 65% de los usuarios desinstalan una aplicación después de dos interacciones fallidas. Los errores no fatales que se dejan sin atender se acumulan y degradan la calidad general. El registro y la corrección sistemática de errores no fatales es un camino directo para mejorar la retención y las calificaciones en las tiendas de aplicaciones.

Tipos de errores no fatales

Errores de red son el tipo más común de errores no fatales en aplicaciones móviles. Tiempo de espera de conexión, pérdida de red, código de estado incorrecto del servidor — todas estas situaciones se capturan y manejan sin cierre. Se muestra al usuario un mensaje de indisponibilidad del servicio con opción de reintentar. El patrón de reintento con retroceso exponencial es típico para errores de red.

Errores de validación de datos

Formato de respuesta incorrecto del servidor, campo obligatorio faltante, tipo de datos inválido — los errores de análisis son no fatales si la aplicación maneja correctamente los datos mal formados. El enfoque típico es usar valores predeterminados de respaldo y registrar el error de análisis con el contexto de la solicitud para su análisis posterior en el servidor.

Errores de representación de UI

Problemas de carga de imágenes, fuentes incorrectas, errores de diseño — todos son no fatales pero degradan la experiencia del usuario. Las imágenes de marcador de posición y los valores de respaldo ayudan a evitar pantallas vacías y hacen que los errores sean menos notorios. En React Native, se usa Error Boundary para errores de UI mostrando un componente alternativo.

Errores de lógica de negocio y estado

Errores de cálculo, discrepancias de estado, transiciones incorrectas entre pantallas — los errores lógicos a menudo no causan un cierre pero llevan a un comportamiento incorrecto de la aplicación. Son más difíciles de detectar sin registro y monitoreo sistemáticos porque no generan un informe de cierre y pasan desapercibidos hasta una queja del usuario.

Non-Fatal Error vs Fatal Error: comparación

Non-Fatal Error se diferencia del fatal en que le deja al programa la posibilidad de continuar funcionando. Un fatal error es un estado del cual la aplicación no puede recuperarse: desreferencia de puntero nulo, desbordamiento de pila, falta de memoria. Un error no fatal puede ser capturado, manejado y la ejecución puede continuar, mientras que un fatal error requiere reiniciar la aplicación.

El límite entre non-fatal y fatal puede depender de la implementación. Un tiempo de espera de red en una aplicación se maneja como no fatal (reintento tras 1–2 segundos), mientras que en otra puede ser fatal (cierre si no hay manejador). Un manejo de errores de calidad convierte situaciones potencialmente fatales en no fatales, aumentando la estabilidad de la aplicación. Diseñar un sistema de manejo de errores es una de las tareas arquitectónicas clave al desarrollar una aplicación móvil con altos requisitos de confiabilidad. Un sistema de monitoreo integrado permite al equipo detectar y corregir rápidamente errores no fatales antes de que afecten a un número significativo de usuarios.

Registro de errores non-fatal

Firebase Crashlytics es la herramienta principal para registrar errores no fatales en aplicaciones móviles. El método recordException permite capturar una excepción no fatal con un stack trace completo y contexto de ejecución sin interrumpir la aplicación. A diferencia de los informes de cierre, recordException se puede llamar en cualquier parte del código para registrar excepciones capturadas.

fun fetchUserData(userId: String) {
    try {
        val response = apiService.getUser(userId)
        updateUI(response)
    } catch (e: IOException) {
        Crashlytics.log("Network error for user $userId")
        Crashlytics.recordException(e)
        showRetryDialog()
    } catch (e: JsonParseException) {
        // Non-fatal: usando datos de respaldo
        Crashlytics.recordException(e)
        showFallbackContent()
    }
}

// Registro con claves personalizadas
Crashlytics.setCustomKey("screen", "Profile")
Crashlytics.setCustomKey("api_version", "v3")

Sentry es una alternativa a Crashlytics con diagnóstico más detallado para errores no fatales. El SDK de Sentry proporciona el método captureException, que envía los detalles de la excepción al servidor. La ventaja clave de Sentry es agrupar errores no fatales similares en un solo issue, analizar la frecuencia de recurrencia y proporcionar contexto de ejecución como breadcrumbs — la secuencia de acciones del usuario antes del error.

Criterios para registrar errores non-fatal

No todos los errores no fatales necesitan registrarse. Los estados esperados — fallo de red cuando no hay conexión — pueden registrarse selectivamente. Los errores inesperados — NullPointerException en código manejado, formato de datos inválido, errores lógicos — deben registrarse siempre. Cada equipo define su umbral de importancia: en promedio, de 10 a 20 errores no fatales únicos por cada 1000 usuarios al día se considera normal. Es importante configurar alertas para un aumento brusco de errores no fatales — esto puede indicar problemas con una nueva versión de la API o una regresión tras un lanzamiento.

Manejo de errores non-fatal en código

El mecanismo básico de manejo es try-catch, que captura la excepción y ejecuta código de recuperación. Para operaciones de red, el patrón típico es reintento con retroceso exponencial. Para errores de análisis, el enfoque es usar valores predeterminados de respaldo y registrar el contexto para su análisis posterior en el servidor.

func loadImage(from url: URL) -> UIImage? {
    do {
        let data = try Data(contentsOf: url)
        return UIImage(data: data)
    } catch {
        Logger.shared.logError(error: "Image load failed: \(url)")
        return UIImage(named: "placeholder")
    }
}

func performRequest() async throws -> Data {
    var lastError: Error? = nil
    for attempt in 0..<3 {
        do {
            return try await URLSession.shared.data(from: url)
        } catch {
            lastError = error
            try await Task.sleep(UInt64(pow(2, attempt)) * 1_000_000_000)
        }
    }
    throw lastError ?? URLError(.unknown)
}

Tipos Result — un enfoque alternativo sin excepciones. Una función devuelve una clase sellada Result con variantes Success y Failure. El código llamante maneja ambas variantes explícitamente, eliminando errores no manejados. Los tipos Result son populares en Kotlin (Result en la biblioteca estándar) y Swift (Result) para el manejo explícito de estados no fatales a nivel de tipos.

Estrategias de respaldo para errores non-fatal

Para cada tipo de error no fatal, se debe planificar una estrategia de recuperación: cargar datos en caché en un error de red, usar valores predeterminados en un error de análisis, reinicializar un componente en un error de UI. Una buena práctica es mostrar al usuario un toast o snackbar con un mensaje de error sin bloquear por completo la interacción con la aplicación. Es importante distinguir entre errores recuperables y no recuperables — para estos últimos, la estrategia de recuperación será diferente, como sugerir reiniciar la pantalla o limpiar los datos. Almacenar en caché el estado exitoso anterior es a menudo la forma más simple y efectiva de manejar errores no fatales en plataformas móviles.