Respuesta.

En Kotlin, el manejo de excepciones se implementa mediante la construcción try/catch/finally, pero se diferencia del enfoque de Java al centrarse en las Unchecked Exceptions y tener una sintaxis más limpia. Una diferencia clave es que en Kotlin no existen las checked exceptions, lo que libera al programador de la obligación de declarar throws y capturar tales excepciones.

Historia de la pregunta

Java utiliza checked/unchecked exceptions, donde las checked requieren una captura o declaración explícita. Esto a menudo conduce a un código redundante y poco conveniente. Kotlin se diseña de una manera más sencilla: todas las excepciones, en general, son unchecked (heredadas de RuntimeException), facilitando el manejo y haciendo el código más legible.

Problema

Los desarrolladores de Java en Kotlin intentan capturar y declarar checked exceptions: el código compila, pero el sentido se pierde. Además, el uso de finally sin comprender los matices puede provocar fugas o código que no funciona.

Solución

Usamos try/catch/finally en Kotlin de manera breve y efectiva:

fun process(data: String): Int = try {
    data.toInt()
} catch (e: NumberFormatException) {
    0
} finally {
    println("Processing done")
}

try/catch/finally puede ser una expresión, es decir, puede devolver un valor que se convierte en el resultado final de la función o se asigna a una variable.
Se pueden capturar varias excepciones, utilizar la construcción when dentro de catch para diferentes reacciones a los tipos de excepciones.

Características clave:

No hay checked exceptions: no es necesario declarar o manejarlas explícitamente.
La construcción try puede funcionar como una expresión (devuelve un resultado).
Se puede usar finally para acciones finales (por ejemplo, cerrar recursos), pero no se deben realizar operaciones que modifiquen el valor de retorno.

Preguntas con trampa.

¿Qué sucede si se lanza una excepción en el bloque finally? ¿Cómo afecta esto al valor de retorno?

Las excepciones lanzadas desde finally siempre sobrescriben cualquier otra excepción o retorno del bloque try/catch, lo que puede llevar a la pérdida de datos importantes sobre la causa del fallo.

fun demo(): Int = try { 1 } finally { throw RuntimeException("error in finally") }

¿Puede try/catch ser una expresión en Kotlin? ¿En qué se diferencia de Java?

Sí. try/catch/finally en Kotlin son expresiones, por lo que pueden devolver un resultado y usarse en lugares donde se permiten valores.

val value = try { risky() } catch (e: Exception) { fallback() }

En Java, son solo declaraciones.

¿Es necesario capturar excepciones en Kotlin si se llama a una función Java externa con throws?

No. Dado que las checked exceptions son ignoradas por el compilador de Kotlin: no es necesario capturarlas explícitamente, pero aún así pueden ser lanzadas durante la ejecución.

Errores comunes y anti-patrones

Captura innecesaria de todas las excepciones (catch (e: Exception)): capturamos lo que no podemos manejar correctamente.
Uso incorrecto de finally: modificación del valor de retorno o lanzamiento de excepciones.
Intentos de usar declaraciones throws dentro del código de Kotlin.

Ejemplo de la vida real

Caso negativo

Insertan catch (e: Exception) en todas partes, sin diferenciar entre errores reales y esperados. Usan finally para devolver un valor, lo que lleva a un comportamiento inesperado en caso de errores.

Ventajas:

Código bastante resistente a cualquier falla.

Desventajas:

Difícil de depurar.
Se pierden mensajes de error y la razón de su aparición.
Se ocultan problemas reales.

Caso positivo

Usan la captura solo de errores esperados, finally solo para limpiar recursos, y utilizan try/catch como expresiones donde esto mejora la legibilidad.