Por qué checkNotNull() no está anotado con @Nonnull

Me pareció inconveniente que la condición previa checkNotNull() en guava no esté marcada con la anotación @Nonull. Consideremos siguiente ejemplo:Por qué checkNotNull() no está anotado con @Nonnull

State(Set<Model> models, Set<Variation> variations) { 
    this.models = checkNotNull(models); 
    this.variations = checkNotNull(variations); 

    if (this.variations == null) { 
    throw new IllegalArgumentException(); 
    } 
    this.engine = createEngine(); 
}

Así IDE no se pudo encontrar que variations == null siempre es falsa. ¿Hay alguna razón particular por la cual esta condición previa no esté marcada con @Nonull (incluso si sus argumentos se definen usando @Nullable).

Fuente

2011-12-05 Denis Bazhenov

Podría perder la opción de enviar un RP para una página wiki de GitHub, porque yo mismo habría escrito algo al respecto. Pero como no puedo, alguien puede agregar al menos un sentencia como "Guava solo usa @Nullable internamente, por lo que todos los tipos de devolución se asumen pero no se marcan con @Nonull" (o similar): https://github.com/google/ guice/wiki/UseNullable – eckes

We haven't used @Nonnull anywhere, lo siento. ¿Por qué? Intentamos agregar más anotaciones de verificación nula, y encontramos que:

Agregar todas las demás anotaciones es muy detallado.
@Nullable es todo lo que necesitamos para NullPointerTester. Es cierto que eso es más importante para los desarrolladores de Guava que los usuarios de Guava.
@Nullable parece haber atrapado la mayoría de los problemas. Admito que es difícil decir cuántos errores no registrados anotaron otras anotaciones antes de que el usuario los encontrara.

La verbosidad era lo principal. Se vuelve loco, especialmente con la subtipificación y con tipos parametrizados. Intentamos elegir un punto ideal para las anotaciones. Tal vez lo cambiemos un día. Por el momento, sin embargo, es por eso que las cosas son como son.

(Si nos hacíamos algo, sospecho que nos gustaría probar a hacer @Nonnull el valor por defecto, utilizando @CheckForNull de las excepciones en su lugar. Pero no he mirado en él siquiera lo suficiente para asegurarse de que tengo los significados derecho .)

Fuente

2011-12-05 16:33:30

Algunas herramientas pueden ser lo suficientemente inteligentes como para notar que el paquete-info está anotado con @ParametersAreNonnullByDefault. –

Pertinente a esta pregunta, creo que también necesitamos @ReturnsAreNonnullByDefault, ¿no? Y no sé si eso existe. –

Hemos establecido todos los paquetes como no nulos de forma predeterminada para parámetros, campos y métodos (valores de retorno). Para los dos últimos tuve que copiar las anotaciones obsoletas de FindBugs. He estado bastante satisfecho con el resultado hasta ahora. En un movimiento que sin duda me morderá más adelante, dupliqué '@ CheckForNull' en un' 'Nullable' privado y prohibí el uso del original porque este último nombre coincide mucho mejor con la intención, es más fácil de escribir y es más legible. . –

De hecho, sería interesante anotar su resultado con @Nonnull, ya checkNotNull() tiros un NPE si la referencia es null, lo que significa que nunca regresa null:

@Nonnull 
    public static <T> T checkNotNull(T reference) { 
    if (reference == null) { 
     throw new NullPointerException(); 
    } 
    return reference; 
    }

Tenga en cuenta que lo que se necesita para cambiar su código para:

if(this.variations == null)

ya que el @Nonnull sólo se aplicaría al resultado de checkNotNull(), pero no dice nada acerca de su argumento. Tenga en cuenta que no podemos anotar el argumento con @Nonnull, ya que a menudo podríamos estar comprobando variables con nulos.

Fuente

2011-12-05 15:00:16

Por qué checkNotNull() no está anotado con @Nonnull

Respuesta

Cuestiones relacionadas