Perché gli errori vengono denominati "Eccezione" ma non come "Errore" nei linguaggi di programmazione?

In realtà ci sto pensando da un po 'di tempo. Non sono un madrelingua inglese, ma ho ancora anni di esperienza di programmazione e me l'ho sempre chiesto. Perché viene chiamato Eccezione ma non Errore poiché sono errori.

Potrebbe essere PageNotFoundErrorinvece di PageNotFoundException.

Non devono essere affatto errori. Il fatto che la pagina non sia presente potrebbe essere solo un fatto interessante piuttosto che un errore reale. Sembrano abituarsi come errori quasi sempre, lo ammetto. Ma a volte vengono utilizzati per uscire dai loop o per farti sapere che una stringa non è un numero valido. Possono essere utilizzati per conservare e restituire grandi quantità di dati utili, come parte di un ritorno abbastanza normale. (Alcune lingue sono un po 'lente con le loro eccezioni, in quel caso lanciarle frequentemente è una cattiva idea.) In teoria, comunque, un'eccezione significa semplicemente "non fare un ritorno normale, vai nello stack di chiamate finché non trovi qualcuno interessato in questo."

Anche un'eccezione puntatore null potrebbe non significare molto per te. Chiami il codice di qualcun altro e quindi ricevi un'eccezione del puntatore null perché sai che può esplodere, stampare un messaggio che dice di chi è la colpa, e andare avanti e portare a termine il tuo lavoro.

Il meccanismo delle eccezioni non è sempre utilizzato per segnalare errori. Vengono generate eccezioni al di fuori delle situazioni ordinarie che richiedono l'elaborazione di un percorso di codice separato, inclusi gli errori. Ad esempio, un utente che fornisce un nome di un file che non esiste o immette una lettera anziché una cifra in un campo numerico, sono situazioni eccezionali che richiedono una gestione speciale, ma non si tratta di errori.

In alcuni ambienti di programmazione, come Java, Errorvengono forniti oggetti speciali per segnalare "errori veri", situazioni che un'applicazione ragionevole non dovrebbe tentare di gestire. Questi oggetti vengono consegnati utilizzando lo stesso meccanismo utilizzato per fornire eccezioni, ma hanno un significato speciale di segnali di situazioni irrecuperabili.

Non ho una ricerca etimologica sulle origini di ciò, ma posso capire che l'uso del termine "Errore" potrebbe non essere preciso in tutte le situazioni; anche come menzionato quasiSharepointMaster, è meglio pensare all'errore e all'eccezione generata come entità separate.

Quando sei in un linguaggio di programmazione di alto livello, ha senso presumere che un'eccezione sia sempre causata da un errore, anche se concordo anche con dasblinkenlight che anche allora un'eccezione non è sempre la conseguenza di un errore. Ad esempio, utilizzo le eccezioni per terminare i thread in modo collaborativo.

La prima volta che ho visto il termine "eccezione" è stato nel manuale di assemblaggio 80386. Ricordo che quando l'ho visto mi è sembrato immediatamente naturale. Chiamare che un errore non sarebbe corretto, perché non ci sono errori in Assembly; ci sono semplicemente condizioni che il processore non può affrontare (se si tratta di un errore - da parte del programmatore, dell'utente o del sistema - beh, il processore è completamente indipendente). Non so se Intel abbia davvero originato il termine o no, ma forse ...

Comunemente l'eccezione è usata per nominare un evento che non è corretto ma da cui può essere recuperato, come out_of_rangeun'eccezione in C ++, che viene generata quando si accede a un elemento in un vettore o in un array che non esiste. Chiaramente un evento del genere non è corretto, ma ciò non dovrebbe significare che l'intero programma si arresti in modo anomalo.

D'altra parte, gli errori vengono generalmente utilizzati per nominare qualcosa che dovrebbe causare il crash di tutto, qualcosa come uno stack overflow è un esempio di un evento che dovrebbe terminare il programma poiché il programma non può gestirlo internamente. In altre parole: un errore è grave, mentre un'eccezione è relativamente minore.

Penso che ciò abbia più a che fare con l '"evoluzione" della gestione degli errori. Con i linguaggi C / C ++ (prima dell'aggiunta della gestione delle eccezioni), se una funzione falliva, l'unico modo per dirlo era attraverso il valore di ritorno (ad esempio HRESULTin win32). Quindi, in genere, hai finito per catturare i codici di uscita di ogni chiamata di funzione ed eseguire un controllo. Questo approccio rende il codice più complicato. E molte volte gli sviluppatori eviteranno semplicemente di aggiungere questi controlli per pigrizia.

Con l'introduzione della gestione delle eccezioni, gli sviluppatori ora avevano due opzioni per sollevare un errore. Quindi la parola "eccezione" è stata utilizzata per distinguere gli errori da "stato di uscita". Dopo un certo periodo di tempo, la gestione delle eccezioni è diventata un modo diffuso per propagare gli errori perché il codice è molto più semplice da leggere, mantenere e può esserci un unico posto in cui è possibile avere una logica di gestione degli errori.

In Python, sono chiamati come ABCError Ad esempio: KeyError, IndexError

http://docs.python.org/library/exceptions.html

Quindi penso che dipenda dal linguaggio che usi.

Quando si verifica un errore, il sistema o l'applicazione attualmente in esecuzione lo segnala generando un'eccezione contenente informazioni sull'errore. Una volta generata, un'eccezione viene gestita dall'applicazione o dal gestore eccezioni predefinito.

Un errore genera un'eccezione che descrive in dettaglio l'errore, quindi non tutto è un errore che è un'eccezione se ciò ha un senso;), ad esempio un'eccezione di nessuna risposta non dovrebbe essere un errore ma genera un'eccezione.

http://msdn.microsoft.com/en-us/library/system.exception.aspx

Nella programmazione iOS / Mac, abbiamo sia Eccezioni che Errori in una sola lingua.

Almeno in quell'ambiente un'eccezione è "non recuperabile", mentre un errore è "recuperabile".

Per esempio:

• se disponi di un array con 10 articoli e provi ad accedere all'articolo all'indice 30, sarà un'eccezione. Hai fatto un errore nella tua programmazione.
• se provi a scaricare un URL ma non esiste una connessione Internet, è prevedibile e dovresti presentare un messaggio all'utente.

Le eccezioni in genere bloccano l'app, mentre gli errori in genere restituiscono nile un oggetto errore (restituito come parametro del metodo di riferimento). È possibile rilevare le eccezioni con un blocco try / catch / finally, ma si consiglia di non utilizzare mai questa funzione del linguaggio: se è possibile ripristinare un'eccezione in qualsiasi modo, non si dovrebbe assolutamente generare un'eccezione (è necessario restituire invece un oggetto errore).

Un errore è qualcosa che è andato storto nell'esecuzione del programma. Spesso questo viene risolto sollevando un'eccezione , ma

• non c'è nulla che costringa un programmatore a gestire un errore sollevando un'eccezione, e
• non c'è nulla che costringa un programmatore a sollevare eccezioni solo in caso di errore.

L'errore è un concetto semantico : viene applicato dal programmatore o dall'utente, che arriva al programma con aspettative, per descrivere la differenza tra le loro aspettative e la realtà. Solo una persona può dire se una routine è in uno stato di errore o meno.

Un'eccezione è un concetto sintattico : è qualcosa nel programma stesso, indipendente dalle aspettative di chiunque riguardo a cosa dovrebbe fare quel programma. Una routine fa o non genera un'eccezione, indipendentemente da ciò che qualcuno pensa.

Eccezioni ed errori sono diversi.

Le eccezioni sono situazioni che un programma può superare, ad esempio se si tenta di aprire un file e non esiste, mentre gli errori sono situazioni in cui un programma non può fare nulla, come un errore del disco o un errore della RAM.

La raccolta e la gestione delle eccezioni sono caratteristiche del flusso di controllo e il nome dell'eccezione dovrebbe seguire l'uso intenzionale. Il progettista di codice e API dovrebbe trovare schemi di denominazione validi e coerenti.

Quindi la risposta alla tua domanda è: dipende dal contesto e dalla prospettiva.

Le eccezioni si sono evolute come generalizzazione degli errori. Il primo linguaggio di programmazione a includere un meccanismo di eccezione fu Lisp nei primi anni '70. C'è un buon riassunto in A Pattern of Language Evolution di Gabriel e Steele. Eccezioni (che non erano ancora chiamate eccezioni) derivavano dalla necessità di specificare il comportamento di un programma in caso di errore. Una possibilità è di interrompere il programma, ma ciò non è sempre utile. Le implementazioni di Lisp hanno tradizionalmente un modo per inserire il debugger in caso di errore, ma a volte i programmatori volevano includere la gestione degli errori nel loro programma. Quindi le implementazioni Lisp degli anni '60 avevano un modo per dire "fai questo, e se si verifica un errore, fallo invece". Inizialmente gli errori venivano dalle funzioni primitive, ma i programmatori trovavano conveniente innescare deliberatamente un errore per saltare una parte del programma e passare al gestore degli errori.

Nel 1972, la forma moderna di gestione delle eccezioni in Lisp è apparsa in MacLisp: throwe catch. Il Software Preservation Group elenca molto materiale sulle prime implementazioni di Lisp, incluso The MACLISP Reference Manual Revision 0 di David Moon . Le primitive catche throwsono documentate in §5.3 p.43.

catchè la funzione LISP per eseguire uscite strutturate non locali. (catch x)valuta xe restituisce i suoi valori, tranne che se durante la valutazione di x (throw y)deve essere valutato, catchrestituisce immediatamente ysenza ulteriore valutazione x.

catchpuò anche essere usato con un argomento econd, non valutato, che viene usato come tag per distinguere tra catture nidificate. (...)

throwè usato catchcome meccanismo di uscita strutturato non locale.

(throw x)valuta xe riporta il valore al più recente catch.

(throw x <tag>)xrestituisce il valore di ritorno al più recente catchetichettato con <tag>o senza etichetta.

L'attenzione si concentra sul flusso di controllo non locale . È una forma di goto (un goto solo verso l'alto), che è anche chiamato un salto . La metafora è che una parte del programma getta il valore per tornare al gestore di eccezioni, e il gestore di eccezioni catture tale valore e lo restituisce.

La maggior parte dei linguaggi di programmazione oggi racchiude il tag e il valore in un oggetto eccezione e combina il meccanismo di cattura con un meccanismo di gestione.

Le eccezioni non sono necessariamente errori. Sono un modo per uscire da un blocco di codice e dai blocchi circostanti, scappando fino a raggiungere un gestore per l'eccezione. Se una cosa del genere sia considerata un "errore" in senso intuitivo è soggettivo.

Alcune lingue fanno una distinzione tra i termini "errore" e "eccezione". Ad esempio, alcuni dialetti Lisp devono entrambi throwsollevare un'eccezione (flusso di controllo per gli utenti, inteso per eseguire un'uscita non locale in un modo che non indica che qualcosa è andato “storto”) e signalper generare un errore (che indica che qualcosa è andato “storto” e potrebbe innescare un evento di debug).

Lo troverai interpretato in modo diverso nelle diverse implementazioni del linguaggio di programmazione. Come ha detto dasblinkenlight, questo è un punto di vista Java di avere una demarcazione tra Errore ed Eccezione. In molti linguaggi di programmazione, le eccezioni sono violazioni che possono essere gestite o che possono essere confuse per passare al modulo di codice più alto possibile. Gli errori sono generalmente situazioni in cui il contenitore di runtime della tua lingua gestisce (e molti casi interrompono semplicemente l'esecuzione).

Un errore è sempre un errore. Un'eccezione è un errore nel contesto corrente. Cioè, un'eccezione è sensibile al contesto. Un esempio di eccezione sarebbe l'aggiunta di un ascii "a" a un numero intero "1". Un errore potrebbe essere qualcosa di simile all'utilizzo di un operatore indefinito come "+!" nella maggior parte delle lingue.

Alcuni linguaggi ti permetteranno di definire la tua via d'uscita dalla situazione se questo è davvero quello che vuoi fare.