Java: E 'ok per impostare Integer = null?

StackOverflow https://stackoverflow.com/questions/2128409

Domanda

Ho una funzione che restituisce un numero ID se l'argomento esiste nel database. In caso contrario, restituisce null. E 'questo l'accattonaggio per un'eccezione di puntatore nullo? numeri ID negativi non sono consentiti, ma ho pensato che sarebbe stato più chiaro di avere argomenti inesistenti ritorno nullo invece di un codice di errore come -1. Cosa ne pensi? 

private Integer tidOfTerm(String name) throws SQLException {
    String sql = "SELECT tid FROM term_data WHERE name = ?";
    PreparedStatement prep = conn.prepareStatement(sql);
    prep.setString(1, name);
    ResultSet result = prep.getResultSet();

    if (result.next()) {
        return result.getInt("tid");
    }

    return null; // TODO: is this begging for a null pointer exception?
}
È stato utile?

Soluzione

Questo è perfettamente legale. Se si vuole evitare un NPE, un'eccezione personalizzata. Ma non restituire un numero negativo. Se il chiamante non controlla il valore di ritorno, si avrà sempre un problema. Ma fare false di calcolo (perché il risultato è per esempio moltiplicato per -1) è sicuramente più difficile da eseguire il debug di un'eccezione uncatched.

Altri suggerimenti

Tornando un null nel caso di una ricerca che non dà un risultato è un normale metodo di rappresentazione non esistenza. Vorrei scegliere in questo caso. (Metodi di ricerca per le classi standard Java Mappa sono un esempio per l'utilizzo di null nel caso in cui la mappa non contiene una chiave.)

Per quanto riguarda la restituzione di un valore speciale per l'ID, vorrei solo proporre di farlo se il sistema contiene già valori speciali repesenting ID speciali di.

Un'altra possibilità spesso sentito è un'eccezione in questo caso. Non è saggio comunque usare eccezioni per passare lo stato, quindi non lo farebbe neanche.

Credo che sia legittimo restituire null in questo caso. Basta fare in modo che l'intenzione è documentato correttamente.

Tornando un valore negativo in questo caso sarebbe stato ok, ma non è una soluzione all-around. Che cosa succede se i valori negativi sono stati ammessi nel db?

Modifica : Voglio aggiungere una parola sui relativi discussioni su quanto riguarda SO null ritorno o elenchi vuoti (o array). Sono a favore del ritorno liste vuote o array invece di nulla, ma il di contesto è diverso. Quando si cerca di ottenere un elenco, è tipicamente parte di un oggetto padre, e rende effettivamente senso per l'oggetto genitore avere un elenco vuoto anziché un riferimento nullo. In questo caso, nulla ha un significato (= non trovato) e non v'è alcuna ragione per evitare di restituirlo.

Spero che questo non è un vero e proprio metodo per voi. Non sta chiudendo Statement o ResultSet nel metodo di applicazione.

  • Non utilizzare un codice di errore! Quale valore è l'errore? sarà che non diventerà mai un valore di ritorno legale? Niente vinto.

  • Null non è buona. La maggior parte del codice chiamante ha a che fare un controllo se non nullo per il risultato. E alcune volte il ristretto, può restituire null. Dovrebbe essere gestito diverso da nessuna riga?

  • un'eccezione come NoSuchElementException invece del nullo ritorno. Si tratta di un'eccezione incontrollato, il chiamante può gestirlo o passare in su. E se il chiamante vuole trattare, il tentativo di cattura non è più complesso di un se non nullo.

vi consiglio di prendere in considerazione l'opzione di modello.

Il modello di opzione agisce come un wrapper per il tipo restituito, e definisce due casi particolari: option.none () e option.some (). In questo modo, si sa sempre il tipo restituito (optional), e può controllare se si dispone di un valore nell'oggetto Opzione restituito utilizzando metodi quali option.isSome () e option.isNone ().

In questo modo, è possibile garantire che non avete i null incontrollati.

Naturalmente, tutto questo viene a costo di complessità codice aggiuntivo.

Per ulteriori informazioni sul tipo di opzione, vedere qui ( codice Scala, ma stesso principio)

No, non lo farà. Sarà solo un tiro NPE se lo si fa operazioni su di esso in seguito come se si tratta di un primitivo, senza nullchecking esso. Per esempio. i++ e così via. Il vostro esempio è valido (si aspetta da che il codice JDBC in sé non è a tenuta risorse). Se non è necessario il id reale, allora si può d'altra parte anche solo restituire un boolean.

Si potrebbe causare grossi guai per gli utenti inesperti. Buone codificatori riconosceranno che se il nome non è valido, allora null potrebbe essere restituito. Dopo aver detto che la cosa più standard è quello di gettare un po 'exception.

Potrebbe essere difficile in combinazione di Autoboxing. Se sto facendo questo: 

final int tid = tidForTerm("term");

E "termine" non esiste, mi metterò un NPE, perché Java tenta di unboxing un intero (null) a un int primitiva.

Tuttavia, ci sono casi in cui è effettivamente un bene di utilizzare null per gli interi. In soggetti aventi valori int opzionali, ad esempio la popolazione di una città. In quel caso nulla significherebbe, non sono disponibili informazioni.

Un problema interessante e un gran numero di soluzioni possibili:

  1. Crea un metodo HasArgument e richiedere agli utenti di chiamare, problema questo può essere un lavoro lento e dupplicate
  2. un'eccezione se un valore non è nel database, deve essere utilizzato solo se questo è inaspettato
  3. Utilizza valori aggiuntivi per indicare un ritorno non valida, valori nulli e negativi avrebbe funzionato per voi, ma se non viene controllato che potrebbe causare problemi più avanti nel codice.
  4. Restituisce un involucro con un'isValid () e un metodo getValue (), dove getValue () genera un'eccezione quando non è valido. Questo risolverebbe i problemi di 1 e 3, ma può essere un po 'troppo mutch.

Direi che la soluzione migliore dipende da ciò che il metodo si chiama, e si dovrebbe prendere in considerazione ciò che i vostri metodi sono chiamati, per quanto se devono restituire null o un'eccezione.

tidOfTerm implica per me che il termine si prevede di esistere, così scoprendo che uno non esiste dovrebbe generare un'eccezione.

Se il nome termine è sotto il controllo del proprio codice, e non trovando indica un bug nel codice o un ambiente, allora si potrebbe desiderare di gettare un IllegalArgumentException.

Se l'argomento nome termine non è sotto il vostro controllo, e non trovando un termine valido è una situazione perfettamente valida, poi mi piacerebbe rinominare il metodo a qualcosa come findTidForTermName dando un leggero sentore che qualche tipo di ricerca sta per essere eseguito, e che v'è quindi la possibilità che la ricerca potrebbe non trovare nulla.

Sono d'accordo con i manifesti. Integer è un wrapper e come tale deve essere utilizzato per i calcoli, le conversioni, ecc (che credo avete intenzione di fare). Non restituire un valore NULL, utilizzare un numero negativo ... è un po 'più elegante e consente un maggiore controllo. IMHO.

Per favore non scrivere codice che restituisce null. Questo significa che ogni chiamata al codice deve Controlla nulla per essere robusta. Ogni volta. Sempre.

Si consideri restituendo una lista invece contenente il numero di valori di ritorno, che potrebbe essere pari a zero.

Si dovrebbe essere la causa di un NPE e sì si dovrebbe essere la cattura che nel metodo di chiamata (o qualche altro luogo adatto). La ragione più probabile per cui il vostro metodo restituirà NULL è quando non ci sono record e il modo corretto di gestire cioè lanciando un'eccezione. E l'eccezione perfetto per dire a qualcuno che non si dispone di quello che ha chiesto è NPE.

invio di un codice di errore (ad esempio -1) non è buono perché:

a) se ci sono molti errori che si desidera gestire (ad esempio non può leggere DB, può leggere DB, ma oggetto non esiste nel DB, trovato oggetto, ma qualcosa è danneggiato, ecc), per poi tornare un codice di errore non fa distinzione tra i tipi di errore.

b) in futuro, se -1 diventa un termine id legale, allora sarà difficile cambiarlo (se è necessario utilizzare -1, poi (EDIT: in C) almeno fare ERRORCODE #define -1 e l'uso ERRORCODE ovunque)

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top