Closed Frozen-Burrito closed 2 years ago
El caso de recursos informativos es interesante. Cuando el usuario no tiene internet y navega a la pestaña "Descubrir" de recursos informativos, el error es otro (un SocketException
) y es manejado por el try/catch en ArticleProvider._fetchArticles()
.
Estas dos excepciones ocurren bajo condiciones similares, pero ambas pueden ocurrir cuando el dispositivo no tiene conexión a internet. Para presentar una abstracción más consistente a las clases que usan la API web, se creó la clase ApiException
, que con su atributo type
puede describir varios posibles errores en la interacción API, como:
En el futuro, será necesario agregar más tipos de ApiException
y mejorar el manejo para los distintos códigos HTTP. Por ejemplo, actualmente una respuesta con status 400 (mala petición) y una con status 401 (no autenticado) resultan en el mismo tipo de ApiException
. Esto es poco flexible y propenso a errores.
Descripción del Error. Cuando la conexión a internet es interrumpida mientras la app está en proceso de hacer una petición HTTP, una
ClientException
es lanzada y no es manejada con un try/catch.Cómo Reproducir Pasos para reproducir el error:
ClientException
que no es manejadoComportamiento Esperado La app debería manejar con gracia las posibles excepciones producidas por causas externas (como una interrupción de conectividad). No debería crashear con ellas.
Entorno
Contexto Adicional Por ejemplo, cuando el método
ArticlesApi.fetchArticles()
es invocado para obtener los recursos informativos desde la API web y la conexión a internet es interrumpida durante la petición, la siguiente excepción es lanzada en la línea 34:ClientException (Software caused connection abort)
Esto debería ser manejado cachando la excepción e indicando visualmente al usuario que los recursos informativos no pudieron ser obtenidos por falta de conexión a internet.