¿Cómo funciona el manejo de excepciones en Kotlin? Describa los matices, las diferencias con Java, el manejo de excepciones checked/unchecked, 'try', 'catch', 'finally', propagación y mejores prácticas. Proporcione un ejemplo.

Respuesta.

Kotlin implementa el manejo de excepciones de manera similar a Java, pero con diferencias importantes. En Kotlin se utilizan las conocidas construcciones try, catch y finally, sin embargo, la diferencia fundamental es que Kotlin no tiene excepciones checked. Esto significa que todas las excepciones (errores en tiempo de ejecución) se consideran unchecked; no es necesario declararlas en la firma de la función ni capturarlas explícitamente.

Puntos clave:

• Los bloques try/catch/finally permiten capturar y manejar excepciones. El bloque finally siempre se ejecuta, incluso si se lanza una excepción.
• Diferencia con Java: en Kotlin todas las excepciones son unchecked. Esto simplifica la sintaxis, pero requiere un enfoque cuidadoso para el manejo de errores.
• Kotlin admite "valor de retorno" del bloque try, es decir, try se puede usar como una expresión, devolviendo el resultado.
• Nuevas idioms: se recomienda evitar el uso de try/catch para el control de flujo; úselos solo para situaciones verdaderamente excepcionales.

fun parseIntOrNull(str: String): Int? = try {
    str.toInt()
} catch (e: NumberFormatException) {
    null
}

Mejores prácticas:

• No usar para controlar la lógica (control de flujo).
• Utilice "gestión de recursos" con use para cierre automático (por ejemplo, archivos).
• No silenciar excepciones con un catch vacío.

Pregunta engañosa.

En Kotlin, ¿es necesario indicar en la firma de la función qué excepciones lanza (como en Java — a través de throws)?

Respuesta correcta: No, en Kotlin no existe el mecanismo de excepciones checked. Todas las excepciones son unchecked. No hay sintaxis throws en la firma de la función (la excepción es la anotación @Throws para compatibilidad con Java, solo para interop).

Ejemplos de errores reales debido al desconocimiento de los matices del tema.

---

Historia

En el proyecto se migró código Java que utilizaba excepciones checked (por ejemplo, IOException). Tras la migración a Kotlin, el desarrollador olvidó manejar la excepción al trabajar con archivos, lo que provocó que la aplicación fallara con archivos reales, ya que nadie manejaba los errores de IO, creyendo que el compilador advertiría como en Java.

---

Historia

Uno de los miembros del equipo utilizó erróneamente try/catch para el control de flujo y ralentizó el análisis de logs (capturaba NumberFormatException para cada cadena inválida — el rendimiento se desplomó con grandes volúmenes de datos).

---

Historia

En un proyecto para JVM, a través de Kotlin, se llamó a código Java que declaraba excepciones checked (throws). El código Kotlin no manejaba las excepciones, creyendo que "todo es unchecked"; como resultado, un error crítico pasó desapercibido hasta un incidente en producción.