Esistono fondamentalmente delle eccezioni per impedire il blocco di un sistema?

Esistono eccezioni per consentire Gestione delle eccezioni , che può evitare arresti anomali ma in generale prevenire comportamenti indesiderati o imprevedibili del sistema. Ad esempio, se la connessione del mio programma a un database è scaduta, di solito non si arresta il sistema, ma se dipendessi dai dati dal database un'eccezione può permettermi di trattare questa situazione senza dati in modo diverso dal normale.

Per impostazione predefinita, il mio programma visualizza una pagina di dati in base a ciò che è stato restituito dal database: beh, non ho dati. Invece di presentare una vista incasinata o continuare un'operazione potenzialmente invalida, posso cogliere questa eccezione e ricorrere a un altro database, leggere dai dati locali, chiedere all'utente dati o altrimenti restituire l'utente o il sistema a uno stato sicuro (presumibilmente uno che non causerà immediatamente la stessa eccezione!)

Inoltre, nei sistemi in cui l'input dell'utente può essere la causa / soluzione di un problema, le eccezioni possono consentire a un utente di conoscere informazioni dettagliate e utili sul problema. Invece del troppo comune "Un'eccezione non gestita avvenuta a ..." o "Intimidazione del messaggio di errore direttamente da SQL", puoi dire all'utente qualcosa di utile o almeno comprensibile come "Impossibile connettersi alla risorsa B".

Sono state create eccezioni per semplificare la gestione degli errori. Senza eccezioni, la logica di gestione degli errori deve essere diffusa in un'applicazione. Qualsiasi funzione che potrebbe causare un errore deve in qualche modo restituire uno stato di errore e ogni chiamata deve essere seguita da un controllo per errore. Spesso il chiamante non può fare nulla di utile in caso di errore e può solo restituire un errore. La metà del codice dell'applicazione può essere dedicata alla gestione degli errori. Tale codice è estremamente fragile. È fin troppo facile escludere un controllo degli errori e crash, o peggio, restituire risultati errati a causa di un errore non notificato.

Con le eccezioni, gli errori possono essere controllati solo nel punto in cui possono essere gestiti. La maggior parte del codice dell'applicazione può essere scritta in modo lineare, poiché le funzioni restituiscono un valore utilizzabile o generano un'eccezione.

Il punto di un'eccezione dovrebbe essere informare l'utente di circostanze eccezionali. Se qualcosa va storto con il sistema, il programma dovrebbe sapere ed essere autorizzato a gestirlo * appropriatamente.

Detto questo, no, non esiste un'eccezione per impedire al sistema di "bloccarsi". Un'eccezione mi sta facendo sapere che c'è un problema. Come procedo determina determinare se il sistema "si blocca".

Nota inoltre che un'eccezione non deve terminare un'applicazione come hai detto tu. Un'eccezione può essere gestita dal programmatore e corretta o trasformata in un errore significativo per l'utente.

* L'uso delle eccezioni controllate (le eccezioni che devono essere catturate) è un po 'un punto dolente. Alcuni (forse la maggior parte) sviluppatori scoprono che la gestione forzata delle eccezioni è ingombrante, non necessaria e solo cattiva pratica.

Le eccezioni consentono la moderna gestione degli errori dividendo il percorso dell'errore dal gestore degli errori. A volte questo è usato anche per il controllo del flusso.

Le eccezioni non gestite terminano un programma. Ma questi non sono diversi dalle precedenti eccezioni, solo un programmatore pigro che ha dimenticato di includere i corretti gestori di errori in ogni percorso li rende visibili all'utente finale. Considero un programma terminato da un'eccezione come se fosse andato in crash come qualsiasi altro fine imprevisto.

I sistemi operativi sono molto utili per pulire i processi in crash, indipendentemente dal modo in cui si sono arrestati, quindi le eccezioni non aggiungono sicurezza per il sistema operativo in altro modo che terminare i processi di malfunzionamento e rilasciando le loro risorse.

È molto semplice.

• Per bloccare solo il programma e non l'intero sistema - abbiamo [buoni] sistemi operativi.
• Per arrestare un programma in modo anomalo invece di ignorare un errore fatale: abbiamo eccezioni.

Prima che le eccezioni fossero inventate, ogni funzione doveva restituire un codice di uscita (errore / successo) e qualsiasi risultato risultato o output dalla funzione doveva essere recuperato passandolo un puntatore alla memoria che deve essere impostato da esso.

Il problema era che molti programmatori non ricordavano / si preoccupavano di controllare i codici di uscita errati per ogni singola funzione, e quindi gli errori fatali venivano a volte ignorati, portando a comportamenti abbastanza inspiegabili.

Pertanto, è stato deciso - quando si verifica un errore, che non hai preso in considerazione, si blocca immediatamente! AKA Exception Handling.

Esistono esecuzioni per separare il normale flusso del programma (ciò che il programma è progettato per fare) dal flusso di gestione degli errori (come il programma sta tentando di recuperare da una situazione eccezionale) .

Questo rende il codice più chiaro e più facile da mantenere.

Considera due sniplet di codice:

try:
    do1()  # this is obvoiusly a normal
    do2()  # program flow
except:
    oups()  # this is exception handling code

Rispetto a questo:

if foo():
    thing1()  # is this part of normal program flow?
else:
    thing2()  # or maybe this one? Or both? When?

Ovviamente, è possibile utilizzare la gestione delle eccezioni per impedire il crash del programma da parte di:

try {    // very bad code
    my();
    whole();
    ugly();
    application();
    here();
} catch (Throwable t) {
    // pretend it's ok
}

ma questo non è il motivo delle eccezioni nei moderni linguaggi di programmazione.

Puoi anche usare while e break invece di if ma questo non è ciò che while e break sono per.

Le eccezioni sono semplicemente un meccanismo di rilevamento degli errori. Da soli non servono a niente.

Ma rilevando un errore, consentono di attivare meccanismi di tolleranza agli errori al fine di recuperare dallo stato errato passando a uno stato privo di errori (uno stato precedente o uno nuovo). In questo modo, l'errore non viene propagato ad altre parti del sistema.