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

In secondo luogo, mi chiedevo se qualcuno sapesse quale fosse la differenza tra le eccezioni (nel regno del flusso di controllo delle eccezioni) e le eccezioni (come quelle utilizzate in Java).

Ma sono lì per proteggere sostanzialmente il sistema dagli arresti anomali chiudendo il programma utente?

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

Supponiamo che il mio programma visualizzi per impostazione predefinita una pagina di dati basata su ciò che è stato restituito dal database - beh, merda, non ho dati. Invece di presentare una vista incasinata o continuare un'operazione potenzialmente non valida, posso rilevare questa eccezione e ricorrere a un database diverso, leggere i dati locali, chiedere dati all'utente o riportare l'utente o il sistema in uno stato sicuro (presumibilmente uno che non causerà immediatamente la stessa eccezione!)

Inoltre, nei sistemi in cui l'input dell'utente potrebbe essere la causa / soluzione di un problema, le eccezioni possono far conoscere all'utente informazioni dettagliate e utili sul problema. Invece del troppo comune "Si è verificata un'eccezione non gestita in ..." 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 comportare un errore deve in qualche modo restituire uno stato di errore e ogni chiamata deve essere seguita da un controllo di 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 tralasciare un controllo degli errori e crash, o peggio, restituire risultati errati a causa di un errore inosservato.

Con 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 quello di informare l'utente di circostanze eccezionali. Se qualcosa va storto con il sistema, il programma dovrebbe sapere ed essere autorizzato a gestirlo * in modo appropriato.

Detto questo, no, non esiste un'eccezione per impedire il "crash" del sistema. Un'eccezione mi sta facendo sapere che c'è un problema. Il modo in cui procedo determina può determinare se il sistema "si arresta in modo anomalo".

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

* L'uso di eccezioni controllate (eccezioni che sono costrette a essere catturate) è un po 'un punto dolente. Alcuni (forse la maggior parte) sviluppatori ritengono che la gestione forzata delle eccezioni sia ingombrante, non necessaria e solo cattiva pratica.

Le eccezioni consentono la moderna gestione degli errori suddividendo la posizione dell'errore dal gestore degli errori. A volte questo viene utilizzato anche per il controllo del flusso.

Le eccezioni non gestite terminano un programma. Ma queste non sono diverse dalle precedenti eccezioni, solo un programmatore pigro che ha dimenticato di includere gestori di errori adeguati in ogni percorso li rende visibili all'utente finale. Ritengo che un programma terminato per eccezione sia andato in crash come qualsiasi altro fine imprevisto.

I sistemi operativi sono molto efficaci nel ripulire i processi bloccati, indipendentemente dal modo in cui si sono arrestati in modo anomalo, quindi le eccezioni non aggiungono sicurezza per il sistema operativo se non per interrompere i processi malfunzionanti e liberare le loro risorse.

È molto semplice.

• Per bloccare solo il programma e non l'intero sistema, abbiamo [buoni] sistemi operativi.
• Arrestare un programma invece di ignorare un errore fatale - abbiamo delle eccezioni.

Prima che fossero inventate le eccezioni, ogni funzione doveva restituire un codice di uscita (errore / esito positivo) e qualsiasi risultato o output della funzione doveva essere recuperato passandogli un puntatore alla memoria da impostare.

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

Pertanto, è stato deciso: quando si verifica un errore, che non hai preso in considerazione, si blocca immediatamente! Gestione eccezioni AKA.

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

Ma rilevando un errore, consentono di innescare 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.

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

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

Prendi in considerazione 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?

Naturalmente, la gestione delle eccezioni può essere utilizzata per impedire l'arresto anomalo del programma:

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 whilee breakinvece di ifma questo non è cosa whilee cosa serve break.