2011-12-05 14 views
7

Uznałem za niedogodne, że warunek checkNotNull() w guava nie jest oznaczony adnotacją @Nonull. Rozważmy następujący przykład:Dlaczego checkNotNull() nie ma adnotacji @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(); 
} 

Więc IDE nie mógł znaleźć że variations == null jest zawsze fałszywe. Czy są jakieś szczególne powody, dla których ten warunek wstępny nie jest oznaczony jako @Nonull (nawet jeśli jego argumenty są zdefiniowane przy użyciu @Nullable).

+1

Może mi brakować opcji wysłania PR dla strony wiki GitHub, ponieważ sam bym coś takiego napisał. Ale skoro nie mogę, ktoś może dodać przynajmniej sentende takie jak "Guava używa tylko @Nullable wewnętrznie, więc wszystkie typy zwracane są wzięte, ale nie oznaczone @Nonull" (lub podobne): https://github.com/google/ guice/wiki/UseNullable – eckes

Odpowiedz

9

We haven't used @Nonnull anywhere, przepraszam. Czemu? Próbowaliśmy dodać więcej adnotacji sprawdzających wartości null i stwierdziliśmy, że:

  • Dodawanie wszystkich innych adnotacji jest bardzo szczegółowe.
  • @Nullable to wszystko, czego potrzebujemy dla NullPointerTester. Co prawda jest to ważniejsze dla programistów Guava niż użytkowników Guava.
  • @Nullable wydawało się, że złapały większość problemów. Przyznaję, że ciężko jest stwierdzić, ile błędów niezatwierdzonych znalazłyby inne adnotacje, zanim użytkownik je znalazł.

Gadność była najważniejsza. Robi się szalony, szczególnie z podtypem i sparametryzowanymi typami. Próbowaliśmy wybrać odpowiednie miejsce na adnotacje. Może kiedyś to zmienimy. W tej chwili jednak tak właśnie jest.

(Jeśli coś zrobiliśmy, podejrzewam, że spróbujemy ustawić domyślną wartość @Nonnull, używając zamiast tego @CheckForNull. Ale nie zajrzałem na to wystarczająco dużo, aby upewnić się, że mam odpowiednie znaczenie .)

+5

Niektóre narzędzia mogą być wystarczająco inteligentne, aby zauważyć, że informacje o pakiecie mają adnotację @ParametersAreNonnullByDefault. –

+4

Ważne na to pytanie Myślę, że potrzebujemy również @ReturnsAreNonnullByDefault, prawda? I nie wiem, czy to istnieje. –

+0

Ustawiliśmy domyślnie wszystkie pakiety na wartość inną niż null dla parametrów, pól i metod (wartości zwracane). W przypadku tych dwóch ostatnich musiałem skopiować nieaktualne adnotacje z FindBugs. Jestem zadowolony z dotychczasowego wyniku. W ruchu, który bez wątpienia ugryzie mnie później, powieliłem '@ CheckForNull' na prywatne' @ Nullable' i zablokowałem użycie oryginału, ponieważ ta druga nazwa lepiej pasuje do celu, jest łatwiejsza do wpisania i jest bardziej czytelna . –

7

To rzeczywiście ciekawe opisywanie jej wynik z @Nonnull, ponieważ checkNotNull() rzuca NPE jeśli odwołanie jest null, co oznacza, że ​​nigdy nie powróci null:

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

Należy pamiętać, że trzeba by zmienić Kod do:

if(this.variations == null) 

od @Nonnull miałby zastosowanie tylko do wyniku checkNotNull(), ale nic nie mówi o jego argument. Zauważ, że nie możemy zanotować argumentu za pomocą @Nonnull, ponieważ często możemy sprawdzać zmienne zerowe.

Powiązane problemy