2016-01-07 3 views
7

Dokumentacja dla Guava Preconditions Uwagi:java.util.Objects.requireNonNull vs Preconditions.checkNotNull

projektów wykorzystujących com.google.common powinna generalnie unikać stosowania Objects.requireNonNull(Object). Zamiast tego należy użyć zależności od tej, która jest odpowiednia dla sytuacji. (To samo dotyczy przeciążania wiadomości.)

Czy ktoś może wyjaśnić powody takiej sugestii?

Czy to jest w celu spójności lub czy jest coś fundamentalnie nie tak z implementacją Objects.requireNonNull?

Odpowiedz

9

To tylko dla spójności. Implementacje są takie same.

+0

Prosto ze źródła. Dziękuję Ci! – vpiTriumph

5

Chociaż od przykład w pytaniu wydaje się, że PO pyta konkretnie o szczególnej formy checkNotNull, jest jeszcze jedna subtelna różnica w ogóle na rzecz korzystania checkNotNull co znajduje odzwierciedlenie w stylu printf varargs formularza. Na przykład przy użyciu Guava Preconditions możesz zrobić następujące:

public void getInput(String companyName) { 
    String context = "Google"; 
    String moreContext = "Facebook"; 
    checkNotNull(companyName, "Why not try %s or %s", context, moreContext); 
} 

z Objects.requireNonNull trzeba będzie coś zrobić jak

public void getInput(String companyName) { 
    String context = "Google"; 
    String moreContext = "Facebook"; 
    checkNotNull(companyName, "Why not try " + context + " or " + moreContext); 
} 

Zobacz: dolny odcinek Preconditions Explained

Proste, varargs „printf stylu "wiadomości wyjątków. (Ta zaleta jest również dlatego zalecamy w dalszym ciągu korzystać z checkNotNull nad Objects.requireNonNull wprowadzony w JDK 7.)

EDIT: Jedno jest jednak, aby pamiętać, że wszystkie argumenty do errorMessageTemplate są konwertowane na ciąg przy użyciu String.valueOf(arg) tak możesz używać tylko% s, a nie innych specyfikatorów, takich jak% d lub% f itp.

+0

Jest to solidny dodatek i należy go bezwzględnie uwzględnić podczas wybierania warunków wstępnych dla Guawy za pomocą 'requireNotNull 'języka Java. – vpiTriumph