Explique las características del trabajo con tipos Nullable en Kotlin. ¿Qué herramientas del lenguaje permiten trabajar de forma segura con valores null? Proporcione un ejemplo de código y describa las mejores prácticas.

Respuesta.

Kotlin implementa un trabajo seguro con null gracias a su sistema de tipos: cualquier tipo por defecto no puede ser null, por ejemplo, val a: String = null generará un error de compilación. Para indicar la posibilidad de asignar null se utiliza el símbolo de interrogación ?, por ejemplo:

val name: String? = null

Para trabajar con tipos Nullable se proporciona:

• Operador de llamada segura: ?., que devuelve null si el objeto mismo es null, y llama al método/campo en caso contrario: name?.length.
• Operador Elvis: ?:, para establecer un valor por defecto si a la izquierda hay null: val length = name?.length ?: 0
• Verificación mediante if/when: Ejemplo:

if (name != null) {
    println(name.length)
}

• Operador assert ( !! ): Para obtener forzadamente un valor, lanzando NullPointerException si el objeto es null (usado con mucha precaución):

val length = name!!.length

Mejores prácticas: minimizar los tipos Nullable, utilizar el operador de llamada segura y el operador Elvis, evitar !!, modelar explícitamente las situaciones en las que se permite null.

Pregunta trampa.

¿Se puede asignar al tipo val a: String un valor null, y cómo evitar esto?

Respuesta: No, por defecto en Kotlin los tipos no pueden ser iguales a null. Para permitir la asignación de null, se debe indicar explícitamente val a: String? = null. Los tipos sin ? siempre son non-null.

Ejemplos de errores reales debido al desconocimiento de las sutilezas del tema.

---

Historia

En un proyecto de aplicación bancaria, una variable de tipo User almacenaba el resultado de la búsqueda de un cliente. El desarrollador definió var user: User, pero a veces el cliente no se encontraba y el servicio devolvía null. Esto causó NPE y caídas masivas.

---

Historia

En un chatbot de soporte se utilizó !! para acceder a los mensajes del usuario (message!!.text), pensando que siempre llegarían mensajes. El bot fallaba en el primer mensaje vacío. La llamada segura habría evitado el problema.

---

Historia

En una aplicación móvil, los datos de la base podían no estar cargados y llegaban como null. En lugar de un acceso seguro, el desarrollador utilizó un acceso directo, lo que llevó a fallos en todos los casos de datos incompletos.