Primero, debe leer todo sobre Seguridad nula en Kotlin, que cubre los casos a fondo.
En Kotlin, no puede acceder a un valor anulable sin estar seguro de que no lo está null( verificar si hay condiciones nulas ), o afirmar que seguramente no está nullutilizando el !!operador seguro , acceder a él con una ?.llamada segura o, por último, dar algo que posiblemente sea nullun valor predeterminado usando el ?:operador de Elvis .
Para su primer caso en su pregunta , tiene opciones dependiendo de la intención del código que usaría uno de estos, y todos son idiomáticos pero tienen resultados diferentes:
val something: Xyz? = createPossiblyNullXyz()
// access it as non-null asserting that with a sure call
val result1 = something!!.foo()
// access it only if it is not null using safe operator,
// returning null otherwise
val result2 = something?.foo()
// access it only if it is not null using safe operator,
// otherwise a default value using the elvis operator
val result3 = something?.foo() ?: differentValue
// null check it with `if` expression and then use the value,
// similar to result3 but for more complex cases harder to do in one expression
val result4 = if (something != null) {
something.foo()
} else {
...
differentValue
}
// null check it with `if` statement doing a different action
if (something != null) {
something.foo()
} else {
someOtherAction()
}
Para el "Por qué funciona cuando nulo marcado", lea la información de fondo a continuación sobre los modelos inteligentes .
Para su segundo caso en su pregunta en la pregunta con Map, si usted como desarrollador está seguro de que el resultado nunca será null, use el !!operador seguro como una afirmación:
val map = mapOf("a" to 65,"b" to 66,"c" to 67)
val something = map.get("a")!!
something.toLong() // now valid
o en otro caso, cuando el mapa PODRÍA devolver un valor nulo pero puede proporcionar un valor predeterminado, entonces Maptiene un getOrElsemétodo :
val map = mapOf("a" to 65,"b" to 66,"c" to 67)
val something = map.getOrElse("z") { 0 } // provide default value in lambda
something.toLong() // now valid
Información de contexto:
Nota: en los ejemplos a continuación estoy usando tipos explícitos para aclarar el comportamiento. Con la inferencia de tipos, normalmente los tipos se pueden omitir para variables locales y miembros privados.
Más sobre el !!operador seguro
El !!operador afirma que el valor no es nullo arroja un NPE. Esto debería usarse en casos en los que el desarrollador garantiza que el valor nunca lo será null. Piense en ello como una afirmación seguida de un elenco inteligente .
val possibleXyz: Xyz? = ...
// assert it is not null, but if it is throw an exception:
val surelyXyz: Xyz = possibleXyz!!
// same thing but access members after the assertion is made:
possibleXyz!!.foo()
Leer más: !! Operador seguro
Más acerca de las nullcuentas de cheques y Smart Casts
Si protege el acceso a un tipo anulable con una marca de nullverificación, el compilador inteligente emitirá el valor dentro del cuerpo de la declaración para que no sea anulable. Hay algunos flujos complicados donde esto no puede suceder, pero para casos comunes funciona bien.
val possibleXyz: Xyz? = ...
if (possibleXyz != null) {
// allowed to reference members:
possiblyXyz.foo()
// or also assign as non-nullable type:
val surelyXyz: Xyz = possibleXyz
}
O si realiza una iscomprobación para un tipo no anulable:
if (possibleXyz is Xyz) {
// allowed to reference members:
possiblyXyz.foo()
}
Y lo mismo para las expresiones 'when' que también son seguras:
when (possibleXyz) {
null -> doSomething()
else -> possibleXyz.foo()
}
// or
when (possibleXyz) {
is Xyz -> possibleXyz.foo()
is Alpha -> possibleXyz.dominate()
is Fish -> possibleXyz.swim()
}
Algunas cosas no permiten el nullchequeo a Smart Cast para el uso posterior de la variable. El ejemplo anterior usa una variable local que de ninguna manera podría haber mutado en el flujo de la aplicación, ya valsea que varesta variable no haya tenido la oportunidad de mutar en a null. Pero, en otros casos donde el compilador no puede garantizar el análisis de flujo, esto sería un error:
var nullableInt: Int? = ...
public fun foo() {
if (nullableInt != null) {
// Error: "Smart cast to 'kotlin.Int' is impossible, because 'nullableInt' is a mutable property that could have been changed by this time"
val nonNullableInt: Int = nullableInt
}
}
El ciclo de vida de la variable nullableIntno es completamente visible y puede asignarse desde otros subprocesos, la nullverificación no puede convertirse de manera inteligente en un valor no anulable. Consulte el tema "Llamadas seguras" a continuación para obtener una solución alternativa.
Otro caso en el que un elenco inteligente no puede confiar para no mutar es una valpropiedad en un objeto que tiene un captador personalizado. En este caso, el compilador no tiene visibilidad de lo que muta el valor y, por lo tanto, recibirá un mensaje de error:
class MyThing {
val possibleXyz: Xyz?
get() { ... }
}
// now when referencing this class...
val thing = MyThing()
if (thing.possibleXyz != null) {
// error: "Kotlin: Smart cast to 'kotlin.Int' is impossible, because 'p.x' is a property that has open or custom getter"
thing.possiblyXyz.foo()
}
Leer más: Verificación de nulo en condiciones
Más sobre el ?.operador Safe Call
El operador de llamada segura devuelve nulo si el valor a la izquierda es nulo; de lo contrario, continúa evaluando la expresión a la derecha.
val possibleXyz: Xyz? = makeMeSomethingButMaybeNullable()
// "answer" will be null if any step of the chain is null
val answer = possibleXyz?.foo()?.goo()?.boo()
Otro ejemplo en el que desea iterar una lista pero solo si no nully no está vacío, nuevamente el operador de llamada segura es útil:
val things: List? = makeMeAListOrDont()
things?.forEach {
// this loops only if not null (due to safe call) nor empty (0 items loop 0 times):
}
En uno de los ejemplos anteriores, tuvimos un caso en el que hicimos una ifcomprobación, pero tuvimos la posibilidad de que otro hilo mutara el valor y, por lo tanto, no hubiera un elenco inteligente . Podemos cambiar esta muestra para usar el operador de llamada segura junto con la letfunción para resolver esto:
var possibleXyz: Xyz? = 1
public fun foo() {
possibleXyz?.let { value ->
// only called if not null, and the value is captured by the lambda
val surelyXyz: Xyz = value
}
}
Leer más: Llamadas seguras
Más sobre el ?:operador de Elvis
El operador de Elvis le permite proporcionar un valor alternativo cuando una expresión a la izquierda del operador es null:
val surelyXyz: Xyz = makeXyzOrNull() ?: DefaultXyz()
También tiene algunos usos creativos, por ejemplo, lanzar una excepción cuando algo es null:
val currentUser = session.user ?: throw Http401Error("Unauthorized")
o regresar temprano de una función:
fun foo(key: String): Int {
val startingCode: String = codes.findKey(key) ?: return 0
// ...
return endingValue
}
Leer más: Operador de Elvis
Operadores nulos con funciones relacionadas
Kotlin stdlib tiene una serie de funciones que funcionan muy bien con los operadores mencionados anteriormente. Por ejemplo:
// use ?.let() to change a not null value, and ?: to provide a default
val something = possibleNull?.let { it.transform() } ?: defaultSomething
// use ?.apply() to operate further on a value that is not null
possibleNull?.apply {
func1()
func2()
}
// use .takeIf or .takeUnless to turn a value null if it meets a predicate
val something = name.takeIf { it.isNotBlank() } ?: defaultName
val something = name.takeUnless { it.isBlank() } ?: defaultName
Temas relacionados
En Kotlin, la mayoría de las aplicaciones intentan evitar nullvalores, pero no siempre es posible. Y a veces nulltiene mucho sentido. Algunas pautas para pensar:
en algunos casos, garantiza diferentes tipos de devolución que incluyen el estado de la llamada al método y el resultado si tiene éxito. Las bibliotecas como Result le dan un tipo de resultado de éxito o fracaso que también puede ramificar su código. Y la biblioteca de Promesas para Kotlin llamada Kovenant hace lo mismo en forma de promesas.
para colecciones como tipos de devolución siempre devuelve una colección vacía en lugar de una null, a menos que necesite un tercer estado de "no presente". Kotlin tiene funciones auxiliares como emptyList()oemptySet() para crear estos valores vacíos.
cuando utilice métodos que devuelvan un valor anulable para el que tiene un valor predeterminado o alternativo, use el operador Elvis para proporcionar un valor predeterminado. En el caso de un Mapuso, getOrElse()que permite generar un valor predeterminado en lugar del Mapmétodo get()que devuelve un valor anulable. Igual porgetOrPut()
al anular métodos de Java donde Kotlin no está seguro acerca de la anulación del código Java, siempre puede eliminar la ?anulación de su anulación si está seguro de cuál debería ser la firma y la funcionalidad. Por lo tanto, su método anulado es más nullseguro. Lo mismo para implementar interfaces Java en Kotlin, cambie la nulabilidad para que sea válida.
mire las funciones que ya pueden ayudar, como for String?.isNullOrEmpty()y String?.isNullOrBlank()que pueden operar con un valor anulable de forma segura y hacer lo que espera. De hecho, puede agregar sus propias extensiones para llenar cualquier espacio en la biblioteca estándar.
La aserción funciona como checkNotNull()y requireNotNull()en la biblioteca estándar.
funciones auxiliares como las filterNotNull()que eliminan valores nulos de las colecciones, o listOfNotNull()para devolver una lista de elementos cero o única de un posible nullvalor.
también hay un operador de conversión Segura (anulable) que permite que una conversión a tipo no anulable devuelva nulo si no es posible. Pero no tengo un caso de uso válido para esto que no se resuelva con los otros métodos mencionados anteriormente.
