Selezionato vs Non selezionato vs Nessuna eccezione ... Una buona pratica di credenze contrarie

All'inizio del C ++ abbiamo scoperto che senza una sorta di programmazione generica, le lingue strongmente tipizzate erano estremamente ingombranti. Abbiamo anche scoperto che le eccezioni controllate e la programmazione generica non funzionavano bene insieme e che le eccezioni controllate erano sostanzialmente abbandonate.

I tipi di ritorno multiset sono ottimi, ma non sostituiscono le eccezioni. Senza eccezioni il codice è pieno di rumore di controllo degli errori.

L'altro problema con le eccezioni controllate è che una modifica delle eccezioni generate da una funzione di basso livello costringe a una cascata di modifiche in tutti i chiamanti, i loro chiamanti e così via. L'unico modo per evitare che ciò accada è che ogni livello di codice rilevi le eccezioni generate dai livelli inferiori e li avvolgano in una nuova eccezione. Di nuovo, si finisce con un codice molto rumoroso.

Per molto tempo i linguaggi OO, l'uso delle eccezioni è stato lo standard di fatto per comunicare errori. Ma i linguaggi di programmazione funzionale offrono la possibilità di un approccio diverso, ad es. usando monadi (che non ho usato), o la più leggera "programmazione orientata alle ferrovie", come descritto da Scott Wlaschin.

• In questo post del blog

• In questa presentazione a NDC 2014

È davvero una variante del tipo di risultato multistato.

• Una funzione restituisce un successo o un errore. Non può restituire entrambi (come nel caso di una tupla).
• Tutti gli errori possibili sono stati sinteticamente documentati (almeno in F # con tipi di risultati come unioni discriminate).
• Il chiamante non può utilizzare il risultato senza prendere in considerazione se il risultato è stato un successo o un fallimento.

Il tipo di risultato potrebbe essere dichiarato come questo

type Result<'TSuccess,'TFail> =
| Success of 'TSuccess
| Fail of 'TFail

Quindi il risultato di una funzione che restituisce questo tipo potrebbe essere un Success o un Fail type. Non può essere entrambi.

In più linguaggi di programmazione orientati all'imperativo, questo tipo di stile potrebbe richiedere una grande quantità di codice sul sito del chiamante. Ma la programmazione funzionale consente di costruire funzioni o operatori vincolanti per unire più funzioni in modo che la verifica degli errori non richieda metà del codice. Ad esempio:

// Create an updateUser function that takes an id, and new state
// as input, and updates an existing user.
let updateUser id input =
    validateInput input
    >>= loadUser id
    >>= updateUser input
    >>= saveUser id
    >>= notifyAboutUserUpdated

La funzione updateUser chiama ciascuna di queste funzioni in successione e ognuna di esse potrebbe fallire. Se tutti riescono, viene restituito il risultato dell'ultima funzione chiamata. Se una delle funzioni fallisce, il risultato di tale funzione sarà il risultato della funzione updateUser complessiva. Tutto questo è gestito dall'operatore personalizzato > > =.

Nell'esempio precedente, i tipi di errore potrebbero essere

type UserValidationErrorType =
| InvalidEmail of string
| MissingFirstName of string
... etc

type DbErrorType =
| RecordNotFound of int
| ConcurrencyError of int

type UpdateUserErrorType =
| InvalidInput of UserValidationErrorType
| DbError of DbErrorType

Se il chiamante di updateUser non gestisce esplicitamente tutti gli errori possibili dalla funzione, il compilatore emetterà un avviso. Quindi hai tutto documentato.

In Haskell esiste una notazione do che può rendere il codice ancora più pulito.

Trovo molto utile la risposta di Pete e vorrei aggiungere qualche considerazione e un esempio. Una discussione molto interessante sull'uso delle eccezioni rispetto alla restituzione di valori di errore speciali può essere trovata in Programmazione in Standard ML, di Robert Harper , alla fine della Sezione 29.3, pagina 243, 244.

Il problema è implementare una funzione parziale f che restituisce un valore di qualche tipo t . Una soluzione è avere la funzione avere tipo

f : ... -> t

e genera un'eccezione quando non c'è alcun risultato possibile. La seconda soluzione è implementare una funzione con tipo

f : ... -> t option

e restituisce SOME v in caso di successo e NONE in caso di fallimento.

Ecco il testo del libro, con un piccolo adattamento fatto da me stesso per rendere il testo più generale (il libro si riferisce a un particolare esempio). Il testo modificato è scritto in corsivo .

What are the trade-offs between the two solutions?

1. The solution based on option types makes explicit in the type of the function f the possibility of failure. This forces the programmer to explicitly test for failure using a case analysis on the result of the call. The type checker will ensure that one cannot use t option where a t is expected. The solution based on exceptions does not explicitly indicate failure in its type. However, the programmer is nevertheless forced to handle the failure, for otherwise an uncaught exception error would be raised at run-time, rather than compile-time.
2. The solution based on option types requires an explicit case analysis on the result of each call. If “most” results are successful, the check is redundant and therefore excessively costly. The solution based on exceptions is free of this overhead: it is biased towards the “normal” case of returning a t, rather than the “failure” case of not returning a result at all. The implementation of exceptions ensures that the use of a handler is more efficient than an explicit case analysis in the case that failure is rare compared to success.

[cut] In general, if efficiency is paramount, we tend to prefer exceptions if failure is a rarity, and to prefer options if failure is relatively common. If, on the other hand, static checking is paramount, then it is advantageous to use options since the type checker will enforce the requirement that the programmer check for failure, rather than having the error arise only at run-time.

Questo riguarda la scelta tra le eccezioni e i tipi di restituzione delle opzioni.

Per quanto riguarda l'idea che la rappresentazione di un errore nel tipo di ritorno porti a un controllo degli errori diffuso in tutto il codice: non è necessario. Ecco un piccolo esempio in Haskell che illustra questo.

Supponiamo di voler analizzare due numeri e poi dividere il primo per il secondo. Quindi potrebbe esserci un errore durante l'analisi di ciascun numero o durante la divisione (divisione per zero). Quindi dobbiamo controllare un errore dopo ogni passaggio.

import Text.Read

parseInt :: String -> Maybe Int
parseInt s = readMaybe s :: Maybe Int

safeDiv :: Int -> Int -> Maybe Int
safeDiv n d = if d /= 0 then Just (n 'div' d) else Nothing

toString :: Maybe Int -> String
toString (Just i) = show i
toString Nothing  = "error"

main = do
         -- Get two lines from the terminal.
         nStr <- getLine
         dStr <- getLine

         -- Parse each string and divide.
         let r = do n <- parseInt nStr
                    d <- parseInt dStr
                    safeDiv n d

         -- Print the result.
         putStrLn $ toString r

L'analisi e la divisione vengono eseguite nel blocco let ... . Si noti che usando la notazione Maybe monad e la notazione do , viene specificato solo il percorso successo : la semantica della Maybe monad propaga implicitamente il valore dell'errore ( Nothing ). Nessun sovraccarico per il programmatore.

Sono diventato un grande fan delle Eccezioni controllate e vorrei condividere la mia regola generale su quando usarle.

Sono giunto alla conclusione che ci sono fondamentalmente 2 tipi di errori che il mio codice deve gestire. Esistono errori verificabili prima dell'esecuzione del codice e errori non verificabili prima dell'esecuzione del codice. Un semplice esempio di errore verificabile prima dell'esecuzione del codice in NullPointerException.

//... bad code below.  the runnable variable
// tries to call the run() method before the variable
// is instantiated.  Running the code below will cause
// a NullPointerException.
Runnable runnable = null;
runnable.run();

Un semplice test potrebbe aver evitato l'errore come ...

Runnable runnable = null;
...
if (runnable != null)
{   runnable.run(); }

Ci sono momenti in informatica in cui è possibile eseguire 1 o più test prima di eseguire il codice per assicurarsi che tu sia sicuro E SARÀ ANCORA OTTENUTO UN ECCEZIONE. Ad esempio, è possibile testare un file system per assicurarsi che ci sia abbastanza spazio su disco sul disco rigido prima di scrivere i dati nell'unità. In un sistema operativo multiprocessing, come quelli utilizzati oggi, il tuo processo potrebbe testare lo spazio su disco e il file system restituirà un valore che dice che c'è abbastanza spazio, quindi un interruttore di contesto in un altro processo potrebbe scrivere i byte rimanenti disponibili per il funzionamento sistema. Quando il contesto del sistema operativo ritorna al processo in esecuzione in cui scrivi i tuoi contenuti su disco, si verificherà un'eccezione semplicemente perché non c'è abbastanza spazio su disco nel file system.

Considero lo scenario sopra come un caso perfetto per un'eccezione controllata. È un'eccezione nel codice che ti costringe ad affrontare qualcosa di brutto anche se il tuo codice potrebbe essere scritto perfettamente. Se scegli di fare cose cattive come "ingoiare l'eccezione", sei il programmatore cattivo. A proposito, ho trovato casi in cui è ragionevole ingoiare l'eccezione, ma per favore lascia un commento nel codice sul motivo per cui l'eccezione è stata ingerita. Il meccanismo di gestione delle eccezioni non è da incolpare. Di solito scherzo che preferirei che il pacemaker cardiaco fosse scritto con un linguaggio che ha Eccezioni controllate.

Ci sono momenti in cui diventa difficile decidere se il codice è testabile o meno. Ad esempio, se si sta scrivendo un interprete e viene generata una SyntaxException quando il codice non viene eseguito per qualche motivo sintattico, la SyntaxException dovrebbe essere un'eccezione controllata o (in Java) una RuntimeException? Risponderei se l'interprete controlla la sintassi del codice prima dell'esecuzione del codice, quindi l'eccezione dovrebbe essere una RuntimeException. Se l'interprete esegue semplicemente il codice "hot" e fa semplicemente clic su un errore di sintassi, direi che l'eccezione dovrebbe essere un'eccezione controllata.

Devo ammettere che non sono sempre felice di dover prendere o lanciare un'eccezione controllata perché ci sono momenti in cui non sono sicuro di cosa fare. Le eccezioni controllate sono un modo per forzare un programmatore a essere consapevole del potenziale problema che può verificarsi. Uno dei motivi per cui programma in Java è perché ha Eccezioni controllate.

Al momento sono al centro di un progetto / API OOP piuttosto grande e ho utilizzato questo layout delle eccezioni. Ma tutto dipende davvero da quanto in profondità si vuole andare con la gestione delle eccezioni e simili.

ExpectedException
 - AuthorisedException
 - EmptySetException
 - NoRemainingException
 - NoRowsException
 - NotFoundException
 - ValidationException

UnexpectedException
 - ConnectivityException
 - EnvironmentException
 - ProgrammerException
 - SQLException

ESEMPIO

   $valid_types = array('mysql', 'oracle', 'sqlite');
       if (!in_array($type, $valid_types)) {
           throw new ecProgrammerException(
        'The database type specified, %1$s, is invalid. Must be one of: %2$s.',
    $type,
    join(', ', $valid_types)
    );
}