Cosa deve succedere quando viene raggiunto il codice che non dovrebbe essere, in base alle regole aziendali o logiche? [duplicare]

Question

Cosa deve succedere quando viene raggiunto il codice che non dovrebbe essere, in base alle regole aziendali o logiche? [duplicare]

#1 da (1 voti)
#2 da (0 voti)

0

Attualmente sto scrivendo un'applicazione che non è enorme ma verrà utilizzata attraverso la mia azienda di oltre 200 persone e clienti esterni sui progetti su cui stiamo lavorando (non su progetti software), ma ci sono una discreta quantità di affari regole, insieme a quelle implicite che riguardano la creazione, la verifica e la gestione degli account utente.

Spesso mi ritrovo a scrivere un codice come questo

If (A)
{
   foo();
}
else If (B)
{
   foo2();
}
else
{
   throw new exception("Should not happen because XYZ");
}

o

foo()
{
   //do stuff    
   if (D == F)
   {
       throw new exception("Method should not be called if D==F, you forgot how to use this method");
   }    
   //do other stuff
}

È questo odore di codice perché implica che il mio codice potrebbe rompersi?

È una buona pratica di programmazione per il debug quando le cose andranno male?

Questo è paranoico?

exceptions code-smell

posta TruthOf42 21.05.2014 - 22:52

fonte

2 risposte

Leggi altre domande sui tag exceptions code-smell

Stabilire una connessione tra classe genitore e figlio Algoritmo rapido per trovare corrispondenze tra due array

score 1 · Answer 1

Dipende tutto dall'importanza di non rovinare le cose quando qualcuno commette un errore o quando SNAFU succede. Presumo che sia importante.

Ad esempio, fornisci un esempio in foo:

throw new exception("Method should not be called if D==F, you forgot how to use this method");

Supponendo che foo non imposti D e F, e il programmatore lo fa, e ovviamente che foo non dovrebbe gestire la situazione in cui D e F sono uguali, è probabilmente la scelta giusta per lanciare un errore. I programmatori sono degli idioti, specialmente quello che usa il tuo codice successivo.

Per verificare che qualcosa abbia avuto successo, non è una cattiva idea se sei in grado di identificare possibili punti di errore. Ad esempio, supponendo un grabber HTTP che restituisce una tupla (integer flag, data object) per qualsiasi motivo:

(flag, page_data) = http_fetch(bleh);
if (flag not in ACCEPTABLE_FLAGS) {
    throw new exception("Today is not a good day.");
}
file_thing.write(page_data.bytes);

Qui, il controllo degli errori significa che nessuno abbatte la tua porta perché Internet è andato giù e di conseguenza il tuo codice ha scalzato i database con spazzatura casuale.

Se è il tuo lavoro, ad es. che hai scritto http_fetch sopra, fai comunque le dichiarazioni. A meno che tu non sia in un ambiente di lavoro davvero terribile e terribile, le persone dovrebbero apprezzare che stai solo riconoscendo che a volte accade lo scenario peggiore.

D'altra parte, è probabilmente eccessivo fare quanto segue:

mid = (low + high)/2;
assert((low <= mid) && (mid <= high));

In breve, se è possibile identificare un punto di errore, coprirlo. Anche se è il tuo codice, a volte le cose vanno male e le supposizioni che hai fatto durante la scrittura di quel codice - come ad esempio che il chiamante avrebbe effettivamente letto i documenti - non sono corrette.

score 0 · Answer 2

Se stai gestendo il caso in cui non ti aspetti che accada qualcosa, allora questo è un motivo perfetto per usare le eccezioni del runtime. Inoltre, dal link (se si utilizza Java, cioè), le eccezioni di runtime dovrebbero essere utilizzato quando il client non può fare nulla per aggirare il problema (come probabilmente è il caso che hai descritto). Se il caso che hai mostrato si verifica, rappresenta un bug di codice, che è quando vengono generate le eccezioni del runtime.

Tuttavia, dovresti farlo solo in pochi casi particolari o speciali, non in ogni singolo metodo nel sistema, che sarebbe paranoico e non fidarti del tuo codice.