Questo codice:
Double.parseDouble("ABC")
lancia un NumberFormatException .
Perché è sbagliato aspettarsi un Double.NaN (NaN è letteralmente Not-A-Number).
Un esempio di lavoro è questo:
public static void main(String[] args) {
System.out.println("Is ABC a number? " + Double.isNaN(Double.parseDouble("ABC"));
}
Mi aspetto Is ABC not a number? true come output.
Perché questa deve essere un'eccezione?
NaN ha un significato molto specifico come risultato di un'operazione numerica indefinita come la divisione per zero o la radice quadrata di un numero negativo (nel regno dei numeri reali). Non è un valore di ritorno appropriato dal codice che analizza un numero in virgola mobile.
Codice come quello che dovrebbe segnalare un errore quando si incontra del testo che non può essere analizzato come un numero.
Inoltre, come altri hanno già detto, è un problema di coerenza. Solo i valori in virgola mobile hanno anche un NaN. I tipi interi e booleani no. parseX () dovrebbe comportarsi allo stesso modo in tutti i casi ove possibile.
Questo è chiamato il principio di sorpresa minima. Cioè, progettare le cose nel modo più coerente possibile per evitare di sorprendere gli altri usando le tue API.
Ciò consente di rilevare facilmente i casi in cui l'input è completamente privo di senso. Puoi analizzare la stringa "NaN" e ottenere NaN, quindi se l'utente volesse darti NaN, potrebbe digitare quello. Il fatto che tu abbia ricevuto "ABC" significa che nemmeno tentavano di inserire un double .
Oltre alla buona risposta di @Doval, lanciare un NumberFormatException è più generale: funziona con metodi simili come Integer.parseInt () . Non esiste un equivalente NaN per ints, shorts, ecc.
Quindi, lanciare un NumberFormatException è sia più specifico / informativo che restituire NaN, è anche più generalizzabile .
Questo è davvero un vantaggio!