Soluzione true-way in Java: analizza 2 numeri da 2 stringhe e poi restituisci la loro somma

Una domanda piuttosto stupida. Dato il codice:

public static int sum(String a, String b) /* throws? WHAT? */ {
  int x = Integer.parseInt(a); // throws NumberFormatException
  int y = Integer.parseInt(b); // throws NumberFormatException
  return x + y;
}

Potresti dire se è un buon Java o no? Quello di cui sto parlando è NumberFormatExceptionun'eccezione incontrollata. Non è necessario specificarlo come parte della sum()firma. Inoltre, per quanto ho capito, l'idea di eccezioni non controllate è solo per segnalare che l'implementazione del programma non è corretta, e ancor di più, catturare eccezioni non controllate è una cattiva idea, poiché è come riparare un programma difettoso in fase di esecuzione .

Qualcuno potrebbe chiarire se:

1. Dovrei specificare NumberFormatExceptioncome parte della firma del metodo.
2. Dovrei definire la mia eccezione controllata ( BadDataException), gestire NumberFormatExceptionall'interno del metodo e rilanciarla come BadDataException.
3. Dovrei definire la mia eccezione controllata ( BadDataException), convalidare entrambe le stringhe in qualche modo come espressioni regolari e lanciare la mia BadDataExceptionse non corrisponde.
4. La tua idea?

Aggiornamento :

Immagina, non è un framework open source, che dovresti usare per qualche motivo. Guardi la firma del metodo e pensi: "OK, non genera mai". Poi, un giorno, hai un'eccezione. È normale?

Aggiornamento 2 :

Ci sono alcuni commenti che dicono che il mio sum(String, String)è un cattivo design. Sono assolutamente d'accordo, ma per coloro che credono che il problema originale non sarebbe mai apparso se avessimo un buon design, ecco una domanda in più:

La definizione del problema è questa: hai un'origine dati in cui i numeri sono memorizzati come Strings. Questa fonte può essere un file XML, una pagina web, una finestra del desktop con 2 caselle di modifica, qualunque sia.

Il tuo obiettivo è implementare la logica che prende questi 2 Strings, li converte in se intvisualizza la finestra di messaggio che dice "la somma è xxx".

Indipendentemente dall'approccio che utilizzi per progettarlo / implementarlo, avrai questi 2 punti di funzionalità interna :

1. Un luogo dove si converte Stringaint
2. Un luogo in cui aggiungi 2 ints

La domanda principale del mio post originale è:

Integer.parseInt()si aspetta che venga passata la stringa corretta . Ogni volta che passi una stringa errata , significa che il tuo programma non è corretto (non "il tuo utente è un idiota"). Devi implementare il pezzo di codice in cui da un lato hai Integer.parseInt () con la semantica MUST e dall'altro devi essere a posto con i casi in cui l'input non è corretto - semantica DOVREBBE .

Quindi, brevemente: come implementare la semantica DOVREBBE se ho solo le librerie MUST .

Questa è una buona domanda. Vorrei che più persone pensassero a queste cose.

IMHO, lanciare eccezioni non controllate è accettabile se ti sono stati passati parametri di spazzatura.

In generale, non dovresti lanciare BadDataExceptionperché non dovresti usare le eccezioni per controllare il flusso del programma. Le eccezioni sono per l'eccezionale. I chiamanti al tuo metodo possono sapere prima di chiamarlo se le loro stringhe sono numeri o meno, quindi il passaggio di spazzatura è evitabile e quindi può essere considerato un errore di programmazione , il che significa che è OK lanciare eccezioni non controllate.

Per quanto riguarda la dichiarazione throws NumberFormatException, questo non è così utile, perché pochi se ne accorgeranno perché NumberFormatException è deselezionato. Tuttavia, gli IDE possono utilizzarlo e offrire di avvolgere try/catchcorrettamente. Una buona opzione è usare anche javadoc, ad esempio:

/**
 * Adds two string numbers
 * @param a
 * @param b
 * @return
 * @throws NumberFormatException if either of a or b is not an integer
 */
public static int sum(String a, String b) throws NumberFormatException {
    int x = Integer.parseInt(a); 
    int y = Integer.parseInt(b); 
    return x + y;
}

MODIFICATO :
I commentatori hanno espresso punti validi. È necessario considerare come verrà utilizzato e il design generale della tua app.

Se il metodo verrà utilizzato ovunque ed è importante che tutti i chiamanti gestiscano i problemi, dichiarare che il metodo genera un'eccezione controllata (costringendo i chiamanti a gestire i problemi), ma ingombra il codice di try/catchblocchi.

Se d'altra parte stiamo usando questo metodo con dati di cui ci fidiamo, dichiaralo come sopra, perché non ci si aspetta che esploda mai e tu eviti l'ingombro di codice di try/catchblocchi essenzialmente non necessari .

A mio parere sarebbe preferibile gestire la logica delle eccezioni il più in alto possibile. Quindi preferirei la firma

 public static int sum(int a, int b);

Con la tua firma del metodo non cambierei nulla. O lo sei

• A livello di codice utilizzando valori errati, dove invece potresti convalidare l'algoritmo del produttore
• o inviando valori, ad esempio, dall'input dell'utente, nel qual caso quel modulo dovrebbe eseguire la convalida

Quindi, la gestione delle eccezioni in questo caso diventa un problema di documentazione .

Numero 4. Come dato, questo metodo non dovrebbe prendere stringhe come parametri, dovrebbe prendere numeri interi. In tal caso (dato che java esegue il wrapping invece di overflow) non c'è possibilità di eccezione.

 x = sum(Integer.parseInt(a), Integer.parseInt(b))

è molto più chiaro su cosa si intende di x = sum(a, b)

Si desidera che l'eccezione avvenga il più vicino possibile alla sorgente (ingresso).

Per quanto riguarda le opzioni 1-3, non definisci un'eccezione perché ti aspetti che i chiamanti presumano che altrimenti il ​​tuo codice non può fallire, definisci un'eccezione per definire cosa accade in condizioni di errore note CHE SONO UNICHE AL TUO METODO. Ad esempio, se hai un metodo che è un wrapper attorno a un altro oggetto e genera un'eccezione, passala. Solo se l'eccezione è unica per il tuo metodo dovresti lanciare un'eccezione personalizzata (frex, nel tuo esempio, se la somma doveva restituire solo risultati positivi, quindi controllarlo e lanciare un'eccezione sarebbe appropriato, se d'altra parte java ha lanciato un'eccezione di overflow invece di wrapping, quindi lo si trasmette, non lo si definisce nella firma, lo si rinominerà o lo si mangerà).

Aggiornamento in risposta all'aggiornamento della domanda:

Quindi, in breve: come implementare la semantica DOVREBBE se ho solo le librerie MUST.

La soluzione a questo è racchiudere la libreria MUST e restituire un valore DOVREBBE. In questo caso, una funzione che restituisce un numero intero. Scrivi una funzione che prenda una stringa e restituisca un oggetto Integer: o funziona o restituisce null (come Ints.tryParse di guava). Fai la tua convalida separatamente dalla tua operazione, la tua operazione dovrebbe richiedere int. Se la tua operazione viene chiamata con valori predefiniti quando hai un input non valido, o fai qualcos'altro, dipenderà dalle tue specifiche - la maggior parte che posso dire a riguardo, è che è davvero improbabile che il luogo per prendere quella decisione sia nell'operazione metodo.

1. Dovrei specificare NumberFormatException come parte della firma del metodo.

Credo di si. È una bella documentazione.

2. Dovrei definire la mia eccezione controllata (BadDataException), gestire NumberFormatException all'interno del metodo e lanciarla nuovamente come BadDataException.

A Volte si. Le eccezioni selezionate sono considerate migliori in alcuni casi, ma lavorare con esse è piuttosto PITA. Ecco perché molti framework (ad esempio, Hibernate) utilizzano solo eccezioni di runtime.

3. Dovrei definire la mia eccezione controllata (BadDataException), convalidare entrambe le stringhe in qualche modo come le espressioni regolari e lanciare la mia BadDataException se non corrisponde.

Mai. Più lavoro, meno velocità (a meno che non ti aspetti che l'eccezione sia una regola) e nessun guadagno.

4. La tua idea?

Proprio nessuno.

Nr 4.

Penso che non cambierei affatto il metodo. Vorrei mettere un tentativo di cattura intorno al metodo di chiamata o superiore nello stack-trace in cui sono in un contesto in cui posso recuperare con grazia con la logica aziendale dall'eccezione.

Non avrei la certezza di fare il n. 3 perché lo ritengo eccessivo.

Supponendo che ciò che stai scrivendo verrà consumato (come un'API) da qualcun altro, allora dovresti andare con 1, NumberFormatException è specificamente allo scopo di comunicare tali eccezioni e dovrebbe essere usato.

1. Per prima cosa devi chiederti se l'utente del mio metodo deve preoccuparsi di inserire dati errati o ci si aspetta che inserisca dati corretti (in questo caso String). Questa aspettativa è anche conosciuta come design by contract .

2. e 3. Sì, probabilmente dovresti definire BadDataException o ancora meglio usare alcune di quelle asportate come NumberFormatException ma piuttosto lasciare il messaggio standard da mostrare. Cattura NumberFormatException nel metodo e rilanciala con il tuo messaggio, senza dimenticare di includere la traccia dello stack originale.

3. Dipende dalla situazione ma probabilmente andrei a rilanciare NumberFormatException con alcune informazioni aggiuntive. E inoltre deve esserci una spiegazione javadoc di quali sono i valori attesiString a, String b

Dipende molto dallo scenario in cui ti trovi.

Caso 1. Sei sempre tu a eseguire il debug del codice e nessun altro e l'eccezione non causerà una cattiva esperienza utente

Lancia il NumberFormatException predefinito

Caso 2: il codice dovrebbe essere estremamente gestibile e comprensibile

Definisci la tua eccezione e aggiungi molti più dati per il debug durante il lancio.

Non hai bisogno di controlli regex perché andrà comunque in eccezione per un input errato.

Se fosse un codice a livello di produzione, la mia idea sarebbe quella di definire più di un'eccezione personalizzata, come

1. Eccezione nel formato del numero
2. Eccezione di overflow
3. Eccezione nulla ecc ...

e trattare tutti questi separatamente

1. Puoi farlo per chiarire che ciò può accadere per un input errato. Potrebbe aiutare qualcuno che usa il tuo codice a ricordare di aver gestito questa situazione. Più specificamente, stai chiarendo che non lo gestisci da solo nel codice o restituisci invece un valore specifico. Ovviamente, JavaDoc dovrebbe chiarire anche questo.
2. Solo se si desidera forzare il chiamante a gestire un'eccezione verificata.
3. Sembra eccessivo. Affidati all'analisi per rilevare input errati.

In generale, un'eccezione NumberFormaException è deselezionata perché è previsto che venga fornito un input analizzabile correttamente. La convalida dell'input è qualcosa che dovresti gestire. Tuttavia, in realtà l'analisi dell'input è il modo più semplice per farlo. Puoi semplicemente lasciare il tuo metodo così com'è e avvertire nella documentazione che è previsto un input corretto e chiunque chiami la tua funzione dovrebbe convalidare entrambi gli input prima di usarlo.

Qualsiasi comportamento eccezionale dovrebbe essere chiarito nella documentazione. O dovrebbe affermare che questo metodo restituisce un valore speciale in caso di errore (comenull , cambiando il tipo di ritorno in Integer) o dovrebbe essere usato il caso 1. Averlo esplicito nella firma del metodo consente all'utente di ignorarlo se garantisce stringhe corrette con altri mezzi, ma è comunque ovvio che il metodo non gestisce questo tipo di errore da solo.

Rispondi alla tua domanda aggiornata.

Sì, è perfettamente normale ricevere eccezioni "a sorpresa". Pensa a tutti gli errori di runtime che si ottengono quando si è nuovi alla programmazione.

e.g ArrayIndexOutofBound

Anche una comune eccezione a sorpresa dal ciclo for each.

ConcurrentModificationException or something like that

Anche se sono d'accordo con la risposta secondo cui dovrebbe essere consentito filtrare l'eccezione di runtime, dal punto di vista del design e dell'usabilità, sarebbe una buona idea inserirla in un'eccezione IllegalArgumentException piuttosto che lanciarla come NumberFormatException. Questo quindi rende più chiaro il contratto del tuo metodo in base al quale dichiara che gli è stato passato un argomento illegale a causa del quale ha lanciato un'eccezione.

Per quanto riguarda l'aggiornamento alla domanda "Immagina, non è un framework open source, che dovresti usare per qualche motivo. Guardi la firma del metodo e pensi:" OK, non genera mai ". Poi, un giorno, hai avuto un'eccezione . È normale?" il javadoc del tuo metodo dovrebbe sempre riversare il comportamento del tuo metodo (vincoli pre e post). Pensa sulle linee di say collection interfaces dove in se un null non è consentito, javadoc dice che verrà lanciata un'eccezione di puntatore null sebbene non faccia mai parte della firma del metodo.

Dato che stai parlando di buona pratica Java, secondo me è sempre meglio

• Per gestire l'eccezione non controllata, analizzala e tramite un'eccezione non selezionata personalizzata.

• Inoltre, mentre lanci un'eccezione personalizzata non selezionata puoi aggiungere il messaggio di eccezione che il tuo client potrebbe comprendere e anche stampare la traccia dello stack dell'eccezione originale

• Non è necessario dichiarare l'eccezione personalizzata come "genera" in quanto è deselezionata.

• In questo modo non stai violando l'uso di ciò per cui sono fatte eccezioni non verificate, allo stesso tempo il client del codice capirebbe facilmente il motivo e la soluzione dell'eccezione.

• Anche documentare adeguatamente in java-doc è una buona pratica e aiuta molto.

Penso che dipenda dal tuo scopo, ma lo documenterei come minimo:

/**
 * @return the sum (as an int) of the two strings
 * @throws NumberFormatException if either string can't be converted to an Integer
 */
public static int sum(String a, String b)
  int x = Integer.parseInt(a);
  int y = Integer.parseInt(b);
  return x + y;
}

Oppure prendi una pagina dal codice sorgente Java per la classe java.lang.Integer:

public static int parseInt(java.lang.String string) throws java.lang.NumberFormatException;

Che ne dici del modello di convalida dell'input implementato dalla libreria "Guava" di Google o dalla libreria "Validator" di Apache ( confronto )?

Nella mia esperienza, è considerata buona pratica convalidare i parametri di una funzione all'inizio della funzione e lanciare eccezioni dove appropriato.

Inoltre, considererei questa domanda in gran parte indipendente dalla lingua. La "buona pratica" qui si applicherebbe a tutti i linguaggi che hanno funzioni che possono assumere parametri che possono essere o non essere validi.

Penso che la tua prima frase di "Una domanda abbastanza stupida" sia molto rilevante. Perché mai scrivere un metodo con quella firma in primo luogo? Ha senso anche sommare due stringhe? Se il metodo chiamante vuole sommare due stringhe, è responsabilità del metodo chiamante assicurarsi che siano int validi e convertirli prima di chiamare il metodo.

In questo esempio, se il metodo chiamante non può convertire le due stringhe in un int, potrebbe fare diverse cose. Dipende davvero a quale livello si verifica questa somma. Suppongo che la conversione della stringa sarebbe molto vicina al codice front-end (se è stata eseguita correttamente), in questo caso 1. sarebbe il più probabile:

1. Imposta un messaggio di errore e interrompi l'elaborazione o reindirizza a una pagina di errore
2. Restituire falso (ovvero, metterebbe la somma in qualche altro oggetto e non sarebbe richiesto di restituirlo)
3. Lancia un po 'di BadDataException come suggerisci, ma a meno che la somma di questi due numeri non sia molto importante, questo è eccessivo e, come accennato in precedenza, questo è probabilmente un cattivo design poiché implica che la conversione viene eseguita nel posto sbagliato

Ci sono molte risposte interessanti a questa domanda. Ma voglio ancora aggiungere questo:

Per l'analisi delle stringhe, preferisco sempre utilizzare "espressioni regolari". Il pacchetto java.util.regex è lì per aiutarci. Quindi finirò con qualcosa del genere, che non genera mai alcuna eccezione. Spetta a me restituire un valore speciale se voglio rilevare qualche errore:

import java.util.regex.Pattern;
import java.util.regex.Matcher;

public static int sum(String a, String b) {
  final String REGEX = "\\d"; // a single digit
  Pattern pattern = Pattern.compile(REGEX);
  Matcher matcher = pattern.matcher(a);
  if (matcher.find()) { x = Integer.matcher.group(); }
  Matcher matcher = pattern.matcher(b);
  if (matcher.find()) { y = Integer.matcher.group(); }
  return x + y;
}

Come si può vedere, il codice è solo un po 'più lungo, ma possiamo gestire ciò che vogliamo (e impostare i valori di default per x e y, controllare cosa succede con le clausole else, ecc ...) Potremmo anche scrivere una trasformazione più generale routine, a cui possiamo passare stringhe, valori di ritorno predefiniti, codice REGEX da compilare, messaggi di errore da lanciare, ...

Spero sia stato utile.

Avviso: non sono stato in grado di testare questo codice, quindi scusa eventuali problemi di sintassi.

Affronti questo problema perché lasci che gli errori dell'utente si propagino troppo in profondità nel nucleo dell'applicazione e in parte anche perché abusi dei tipi di dati Java.

Dovresti avere una separazione più chiara tra la convalida dell'input dell'utente e la logica aziendale, utilizzare una corretta tipizzazione dei dati e questo problema scomparirà da solo.

Il fatto è che la semantica di Integer.parseInt()are known - il suo scopo principale è analizzare interi validi . Ti manca un passaggio esplicito di convalida / analisi dell'input dell'utente.