hechas - ¿Hacer que Kotlin advierta sobre la asignación de tipo flexible/plataforma a tipo no nulo?

kotlin ventajas y desventajas

Question

Cuando se llama a una función Java anotada que no es nulable de Kotlin, obtenemos valores de retorno de tipo flexible, denotados por signos de exclamación, por ejemplo String! .

Kotlin permite silenciosamente asignar estos valores flexibles a un tipo normal que no sea nulo, por ejemplo, String , lo que puede causar NullPointerExceptions en tiempo de ejecución.

Preferiría obtener advertencias o errores del compilador para tales asignaciones. Alternativamente, trate los tipos de plataforma como equivalentes a los tipos anulables (por ejemplo String? ).

Como ejemplo, con este código Java:

import android.os.SystemClock;
import android.support.annotation.NonNull;
import android.support.annotation.Nullable;

public class NullTest {

    private String maybe() {
        if (SystemClock.elapsedRealtimeNanos() % 2 == 0) {
            return null;
        }
        return "ok";
    }

    public String annotatedNothing()            { return maybe(); }
    @Nullable public String annotatedNullable() { return maybe(); }
    @NonNull  public String annotatedNonNull()  { return "ok"; }

}

... y el siguiente código de Kotlin, me gustaría obtener errores en dos líneas nuevas (ver comentarios):

fun testnulls() {
    val obj = NullTest()

    val nullExact: String  = obj.annotatedNullable() // already gives an error
    val nullMaybe: String? = obj.annotatedNullable()
    val nullInfer          = obj.annotatedNullable()

    val okayExact: String  = obj.annotatedNonNull()
    val okayMaybe: String? = obj.annotatedNonNull()
    val okayInfer          = obj.annotatedNonNull()

    val bareExact: String  = obj.annotatedNothing() // I want a compiler error here
    val bareMaybe: String? = obj.annotatedNothing()
    val bareInfer          = obj.annotatedNothing()

    print("length " + nullExact.length)
    print("length " + nullMaybe.length) // already gives an error
    print("length " + nullInfer.length) // already gives an error

    print("length " + okayExact.length)
    print("length " + okayMaybe.length) // already gives an error
    print("length " + okayInfer.length)

    print("length " + bareExact.length)
    print("length " + bareMaybe.length) // already gives an error
    print("length " + bareInfer.length) // I want a compiler error here
}

El punto es que esto me obligará a agregar cheques nulos o !! , asegurándome de que al menos tengo que ser explícito al respecto.

es posible?

En los comentarios de esta publicación del blog de 2014 JetBrains , cuando introdujeron plataformas / tipos flexibles, parece que estaban planeando agregar una opción para advertir sobre estas situaciones exactamente, pero no he podido encontrar más información al respecto.

Answer 1

La documentation Kotlin describe este caso exacto:

Cualquier referencia en Java puede ser nula, lo que hace que los requisitos de Kotlin de estricta seguridad nula no sean prácticos para los objetos procedentes de Java. Los tipos de declaraciones de Java se tratan especialmente en Kotlin y se llaman tipos de plataforma. Los controles nulos son relajados para tales tipos, por lo que las garantías de seguridad para ellos son las mismas que en Java

Desafortunadamente, significa que no hay forma de emitir una advertencia durante un tiempo de compilación. El lado positivo es que Kotlin al menos evitará que el nulo se propague en el tiempo de ejecución.

Cuando llamamos a métodos en variables de tipos de plataforma, Kotlin no emite errores de nulabilidad en tiempo de compilación, pero la llamada puede fallar en tiempo de ejecución, debido a una excepción de puntero nulo o una afirmación que Kotlin genera para evitar que se propaguen nulos

Si no controlo el código fuente de una biblioteca de Java que uso, trato todos los resultados como potencialmente anulables, a menos que sea evidente que no lo son.

Answer 2

Sí, es posible obtener advertencias y / o errores del compilador para cualquier asignación de los métodos de Java con la suposición de que si el método no tiene la anotación @Nullable es @Nullable .

¿Cómo? :) Tendrá que escribir su propio complemento de Inspección Personalizada de Idea .

Aquí hay algunos enlaces útiles para cualquier persona con experiencia suficiente para crear ese complemento de inspección personalizado (probablemente estaría entre sus usuarios agradecidos):

1. Guía de inicio rápido para el desarrollo de complementos de ideas
2. Fuentes de todas las inspecciones de Idea Kotlin existentes (podrían ser útiles como ejemplos de comprobaciones de seguridad nulas existentes)

Si está familiarizado y tiene experiencia en el desarrollo de complementos de Idea, es posible que no lleve mucho tiempo. De lo contrario, no creo que el resultado que usted va a lograr realmente valga la pena el tiempo que tendrá que gastar.

Me gusta su idea, pero AFAIK en las primeras etapas del desarrollo de kotlin hubo un intento de implementar los controles de seguridad más nulos que fuera posible y resultó que había demasiadas tareas potencialmente inseguras.

ps. Si finalmente va a construir ese complemento de inspección, por favor hágamelo saber. Yo personalmente intenté hacerlo, pero en mi caso, primero tendré que aprender más sobre los complementos de Idea.

Answer 3

para cadenas no nulas -

Compruebe isEmpty (). No podrá pasar cadenas que no sean nulas en ese método. Así que es de tipo seguro.

para cuerdas nulas -

Usted puede marcar nulo en si condición.