Cuando desarrollas un programa, te enfrentas constantemente a la gestión de los errores que pueden surgir. Inicialmente, puede que utilices simples bloques try-catch para manejar excepciones, pero a medida que tu programa crece, te encuentras navegando entre varios de estos bloques para identificar el origen de los problemas. Para evitar este desorden en el manejo de errores y mejorar la legibilidad del código, te presento el objeto Result
en Kotlin. Este objeto puede ayudarte a mantener un código más limpio y una gestión de errores más organizada, lo que facilita el mantenimiento a largo plazo.
El objeto Result
en Kotlin es una herramienta que permite representar tanto casos exitosos como errores en una operación. Tiene dos tipos de datos: Success
, que puede ser de cualquier tipo, y Failure
, que representa una excepción. Esta distinción proporciona una forma clara y explícita de manejar cada situación.
Para ilustrar su uso, comencemos con un ejemplo utilizando bloques try-catch y luego veamos cómo se puede mejorar utilizando el objeto Result
.
fun findBy(userId: String): User {
return try {
repository.getUser(userId)
} catch (e: Exception) {
// Aquí se pueden manejar excepciones esperadas e inesperadas
}
}
En este código, estamos intentando obtener un usuario desde un repositorio. Es probable que esta operación pueda lanzar diversas excepciones, algunas esperadas y otras no. Con el enfoque tradicional de try-catch, terminamos con un código difícil de leer y mantener.
En cambio, con el objeto Result
, el código se simplifica:
fun findBy(userId: String): Result<User> {
return runCatching {
repository.getUser(userId)
}
}
En este ejemplo, runCatching
es un método de Kotlin que internamente utiliza un bloque try-catch y devuelve un objeto Result
, que encapsulará la excepción como respuesta o la respuesta esperada (User). Esto hace que la función findBy
quede mas sencilla y a la hora de manejar los errores quedaría de una forma mas explicita.
fun main() {
val result = findBy("123")
result.fold(
onSuccess = {
// Manejar el resultado exitoso
},
onFailure = {
// Manejar las posibles excepciones
when (it) {
is UserNotFoundException -> // Caso esperado
else -> // Caso inesperado
}
}
)
}
Una de las mayores ventajas de trabajar con este objeto está en su API, que nos provee de ciertos métodos para manejar el contenido de manera explícita e implícita. Algunos de ellos son el fold
, el map
, isFailure
, isSuccess
, exceptionOrNull
, getOrNull
, getOrDefault
, getOrElse
, getOrThrow
, recover
. Una de las más usadas es el fold
ya que nos permite interactuar directamente con ambos caminos.
En este ejemplo lo resolvemos utilizando la función fold
del objeto Result
para manejar los casos de éxito y fracaso de manera explícita. Cuando un resultado es exitoso, se ejecuta el bloque de código proporcionado en onSuccess
, y cuando hay un fallo, se ejecuta el bloque de código en onFailure
. Esto junto al uso de la expresión when
, en el caso fallido, proporciona un manejo claro y estructurado de las excepciones de las operaciones.
En los últimos meses, he trabajado bastante con el objeto Result
. Al principio, me llevó un tiempo acostumbrarme a su uso, pero una vez comprendí su funcionamiento, lo encontré como una herramienta poderosa y cómoda para manejar errores en mis aplicaciones. Me ha permitido evitar la tediosa tarea de rastrear errores en la aplicación y comprender rápidamente cómo se gestionan. Si nunca has utilizado Result
antes, ya sea por miedo a la complejidad o por falta de conocimiento, te animo a que lo pruebes e investigues mas sobre el objeto. Te ahorrará muchos dolores de cabeza y mejorará la calidad y legibilidad de tu código.
¿Quieres más? te invitamos a suscribirte a nuestro boletín para avisarte cada vez que recopilemos contenido de calidad que compartir.
Si disfrutas leyendo nuestro blog, ¿imaginas lo divertido que sería trabajar con nosotros? ¿te gustaría?
Pero espera 🖐 que tenemos un conflicto interno. A nosotros las newsletter nos parecen 💩👎👹 Por eso hemos creado la LEAN LISTA, la primera lista zen, disfrutona y que suena a rock y reggaeton del sector de la programación. Todos hemos recibido newsletters por encima de nuestras posibilidades 😅 por eso este es el compromiso de la Lean Lista