Utilizzo di numeri negativi per restituire condizioni di errore

Spesso dipende dalla lingua. Abbastanza pratica comune in linguaggi come C e C ++, ma dove esistono altri meccanismi è preferibile usarli, ad esempio le eccezioni. Consentono il disaccoppiamento - concettuale e in codice - dell'uso del risultato del metodo dall'affrontare errori.

int result = myFunction();
if (result < 0) dealWithError(result);
else proceedNormally();

è probabilmente meno facile da ragionare e codice rispetto a un blocco try-catch (che può essere posizionato ovunque nella gerarchia chiamante, senza la necessità esplicita di propagare i risultati degli errori - anche se alcuni linguaggi come Java richiedono / raccomandano una modifica della firma Ad esempio

myFunctionChecked() {
   try {
      myMethod();
   }
   catch (Exception e){
      dealWithExcpetion(e)
   }
}

e

myOtherFunctionChecked() {
   try {
      myOtherFunction();
   }
   catch (Exception e){
       dealWithExcpetion(e)
   }
}
myOtherFunction() {
   //... some stuff
   myFunction();
   //... some other stuff
}

possono essere entrambi utilizzati senza alcuna modifica al modo in cui myFunction segnala i propri errori se vengono utilizzate eccezioni.

Il punto finale per le eccezioni è che ti consentono di essere coerenti su come segnalare errori nel codice, non in base all'intervallo della funzione.

(...), would it be good practice to use negative numbers to define error conditions?

Fornire messaggi di errore e valori di ritorno validi usando lo stesso canale è raramente una buona idea.

Guarda come su un tipico standard input , output e error sono separati - prova a rispecchiarlo nella tua applicazione. Se la tua lingua preferita prevede costrutti dedicati alla gestione degli errori (ad esempio eccezioni): usali; tratta i codici di errore restituiti come metodo di ultima istanza se non è disponibile altro.

È più facile pensare al flusso di controllo del tuo programma se puoi essere sicuro che un canale sempre fornisce dati validi senza ambiguità (se i tuoi "dati validi" possono essere "valore restituito" o " messaggio di errore "non puoi essere sicuro che i dati restituiti da una funzione siano sempre validi.

Il sovraccarico del significato di qualsiasi codifica è una cosa pericolosa .

Qui un codice messaggio significa entrambi:

• successo / fallimento
• Id è il messaggio specifico

Ecco come si evolverà questo doppio significato:

• I programmatori futuri malediranno l'API quando capiranno che devono inviare un messaggio per poter dire "successo".
• I futuri programmatori futuri malediranno il progetto quando realizzeranno che "-999" è stato dirottato per significare "falso senza messaggio", ma è all'interno del dominio degli ID messaggio validi.
• Analisi dei valori letterali stringa "true" e "false". O "successo" e "fallimento". Molto probabilmente entrambi.
• Memorizzare effettivamente i caratteri dello spazio come valore nel database.
• Potrebbero esserci elenchi di numeri "black listed" e "white listed", come sopra. Molto probabilmente semplicemente codificato in linea in vari punti.
• Tutti si chiederanno che idiota non capisce "null" o "true / false"
• Ci sarà un codice di gestione eccezionale ovunque.

Per favore perdona la durezza, un po 'di PTSD che sta succedendo qui.

• Lì sarà un momento in cui ciò influirà negativamente sulla manutenzione.
• Lo sforzo di manutenzione è O (n * 2) perché dobbiamo occuparci anche del database.

In passato ho usato un sistema in cui un valore di ritorno di 0 significava successo, qualsiasi valore positivo significava successo con alcune annotazioni che il chiamante poteva interpretare in qualche modo, e qualsiasi valore negativo significava un errore.

Con questo sistema è stato generalmente possibile verificare il successo o il fallimento molto facilmente. Se un metodo ha restituito più status è stato facilmente possibile verificarlo. Ed è stato facilmente possibile verificare esattamente quale errore si è verificato.