"use" abc ".equals (myString) invece di myString.equals (" abc ") per evitare l'eccezione puntatore nullo" già problematico in termini di business logic?

Question

"use" abc ".equals (myString) invece di myString.equals (" abc ") per evitare l'eccezione puntatore nullo" già problematico in termini di business logic?

#1 da (15 voti)
#2 da (1 voti)
#3 da (1 voti)
#4 da (0 voti)

6

Ho sentito numerose volte che durante il confronto di stringhe in Java, per evitare l'eccezione del puntatore nullo, dovremmo usare "abc" .equals (myString) invece di myString.equals ("abc"), ma la mia domanda è, è questa idea già problematico in termini di business logic?

Supponi che myString non debba essere vuoto in condizioni normali, se usiamo semplicemente "abc" .equals (myString) per evitare un'eccezione del puntatore nullo, potremmo perdere alcuni bug che sono correlati alla causa principale delle stringhe null (es: a modulo con campo incompleto o una colonna mancante di database corrispondente), quindi dovremmo lasciare che le eccezioni del puntatore nullo vengano generate in modo naturale, o sempre prima di selezionare null separatamente:

if(myString==null){
}else if(myString.equals("abc")){
}

per assicurarci che possiamo trovare bug o almeno avere percorsi per gestire condizioni anomale che causano input nulli, è vero? E anche null è considerato valido, dovrei comunque scrivere qualcosa come:

if(myString==null || myString.equals("")){
}

per sottolineare o ricordare ad altri sviluppatori che ora presumo che null sia normale?

java null strings string-matching

posta ggrr 24.03.2016 - 07:49

fonte

4 risposte

Leggi altre domande sui tag java null strings string-matching

Perché vengono utilizzati i generatori di parser? Qual è la definizione corretta della legge di Moore

score 15 · Answer 1

L'utilizzo di "abc".equals(...) è una precauzione ragionevole contro una condizione che non hai previsto, ma in realtà non risolve alcun problema. Forse questo particolare metodo non interessa che myString sia nullo (il confronto tra stringhe restituisce false, ma è tutto), ma che dire di altrove? Ora c'è questo valore nullo che si sta facendo strada attraverso la tua logica che non dovrebbe essere lì.

In questo caso particolare, potrebbe non avere importanza, ma in un altro, lasciare che questo valore non valido passi attraverso parte della logica potrebbe portare a uno stato errato in seguito (ad esempio, un indirizzo con la città mancante). Fail early!

Se myString non dovrebbe essere nullo, quindi scrivi il codice in modo che non possa essere. Aggiungi contratti ai tuoi metodi, o almeno alcune convalide degli argomenti in-metodo per garantire che i valori non validi siano trattati prima che la logica del metodo venga eseguita. Quindi assicurati che i tuoi test coprano questi casi.

score 1 · Answer 2

Se myString è nullo, una versione genererà un'eccezione, mentre l'altra farà qualcosa in base alla documentazione che dovrei leggere prima. Supponiamo di confrontare una stringa con zero per i rendimenti di uguaglianza "false".

Possibilità: myString non è mai nullo, quindi non importa. O myString è solo nullo in caso di qualche bug nel software, quindi un'eccezione inaspettata che spero possa portare a qualcosa che attiri l'attenzione dello sviluppatore è una buona cosa. (È lì che catturare le eccezioni e non fare nulla con loro è fatale). O myString può essere legalmente zero e si desidera che il confronto restituisca false, quindi confrontare di conseguenza. O myString essendo nil è un caso eccezionale che necessita di una gestione speciale, di cui potresti non essere a conoscenza, quindi un'eccezione inaspettata ti farà aggiungere la corretta gestione ad un certo punto.

Abbastanza divertente, in Objective-C è esattamente il contrario: il confronto con nil genera un'eccezione, confrontando nil con qualsiasi cosa restituisce NO (più o meno come falso). Quindi qualunque cosa tu faccia, uno sviluppatore di Objective-C dovrebbe fare esattamente il contrario!

score 1 · Answer 3

Un obiettivo della programmazione è il codice robusto, vale a dire. codice che non muore orribilmente ogni volta che qualcosa di inaspettato cade.

in caso di if ("abc".equals(myString)) , la clausola if non viene eseguita se la stringa è nullo, quindi non è necessario lanciare un'eccezione. Ovviamente potrebbe essere causato da bug nel codice, ma quelli dovrebbero essere trovati durante lo sviluppo / test, non in produzione, dal cliente!

In realtà, vorrei prendere "abc".equals(myString) come un'indicazione che il programmatore non si preoccupava esplicitamente che la stringa fosse nulla o no. In codice critico, mi aspetterei un controllo molto più esplicito.

score 0 · Answer 4

Using "abc".equals(...) is a reasonable precaution against a condition you didn't anticipate

In realtà mi sono inventato questa soluzione per evitare un NullPointerException pur mantenendo la concisione del codice per la mia azienda circa 2 anni fa. È davvero un approccio ragionevole per me. Lo stile di scrittura di questo può sembrare un po 'strano però. La mia squadra ha effettivamente riso di questo tipo di scrittura, poi si è resa conto che è legittima e questo è ormai stabilito come standard nella nostra organizzazione.