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

Non hanno bisogno di essere errori. Il fatto che la pagina non sia presente potrebbe essere solo un fatto interessante piuttosto che un errore reale. Sembra che si usino quasi sempre come errori, lo ammetto. Ma a volte sono abituati a uscire da loop o ti fanno sapere che una stringa non è un numero valido. Possono essere utilizzati per conservare e restituire grandi quantità di dati utili - come parte di un rendimento 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, andare sullo stack delle chiamate finché non trovi qualcuno interessato in questo. "

Anche un'eccezione di puntatore nullo potrebbe non significare molto per te. Chiami il codice di qualcun altro e poi prendi un'eccezione di puntatore nullo perché sai che è in grado di esplodere, stampare un messaggio che dice di chi è la colpa e continuare il lavoro.

Il meccanismo delle eccezioni non è sempre usato per segnalare errori. Le eccezioni vengono gettate fuori dalle normali situazioni che richiedono un percorso di codice separato da elaborare, inclusi gli errori. Ad esempio, un utente che fornisce un nome di un file che non esiste o che 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, Error oggetti sono forniti per segnalare "errori veri", situazioni che un'applicazione ragionevole non dovrebbe tentare di gestire. Questi oggetti vengono consegnati utilizzando lo stesso meccanismo utilizzato per distribuire le eccezioni, ma hanno un significato speciale di segnali di situazioni irrecuperabili.

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

Quando ti trovi in un linguaggio di programmazione di alto livello, è logico presumere che un'eccezione sia sempre causata da un errore, anche se concordo anche con dasblinkenlight che anche in questo caso un'eccezione non sempre è la conseguenza di un errore. Io, ad esempio, uso le eccezioni per terminare i thread in modo collaborativo.

La prima volta che ho visto il termine "eccezione" era nel manuale di assemblaggio 80386. Ricordo che quando l'ho visto sembrava per me immediatamente naturale. Chiamare quell'errore non sarebbe corretto, perché non ci sono errori in Assembly; ci sono semplicemente condizioni che il processore non può gestire (se si tratta di un errore - dal programmatore, dall'utente o dal sistema - beh, il processore è completamente agnostico a questo). Non so se Intel abbia davvero dato origine al termine o no, ma forse ...

Comunemente Eccezione è usata per nominare un evento che non è corretto ma può essere recuperato da, come un'eccezione out_of_range in C ++, che viene generata quando si accede a un elemento in un vettore o array che non esiste. Chiaramente un tale evento non è corretto, ma ciò non dovrebbe significare che l'intero programma si blocca.

D'altra parte gli errori sono solitamente usati per nominare qualcosa che dovrebbe mandare in crash tutto, qualcosa come un overflow dello stack è un esempio di un evento che dovrebbe terminare il programma in quanto il programma non può gestirlo internamente. In altre parole: un errore è maggiore, mentre un'eccezione è relativamente minore.

Penso che questo abbia più a che fare con "l'evoluzione" della gestione degli errori. Con le lingue C / C ++ (prima della gestione delle eccezioni aggiunte), se una funzione non riusciva, l'unico modo per dirlo era attraverso il valore di ritorno (ad esempio HRESULT in win32). Di solito, alla fine, hai catturato i codici di uscita di ogni chiamata di funzione e fatto un controllo. Questo approccio rende il codice più disordinato. E molte volte gli sviluppatori eviteranno di aggiungere questi controlli per pigrizia.

Con l'introduzione della gestione delle eccezioni, gli sviluppatori ora disponevano di due opzioni per generare un errore. Quindi la parola "eccezione" è stata utilizzata per distinguere gli errori dagli errori di "stato di uscita". Dopo un certo periodo di tempo, la gestione delle eccezioni è diventata un modo diffuso di propagare gli errori perché il codice è molto più facile da leggere, gestire 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

link

Quindi penso che dipenda dal linguaggio che usi.

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

Un errore genera un'eccezione che specifica l'errore, quindi non tutto è un errore che è un'eccezione se ciò ha senso;), ad esempio un'eccezione non importante non dovrebbe essere un errore ma genera un'eccezione.

link

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".

Ad esempio:

• se si dispone di un array con 10 voci e si tenta di accedere all'elemento nell'indice 30, si tratterà di un'eccezione. Hai commesso un errore nella tua programmazione.
• se provi a scaricare un URL ma non ci sono connessioni Internet, è normale che tu debba presentare un messaggio all'utente.

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

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 ad aumentare le 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 realtà. Solo una persona può dire se una routine si trova in uno stato di errore o meno.

Un'eccezione è un concetto sintattico : è qualcosa nel programma stesso, indipendente dalle aspettative di chiunque su cosa dovrebbe fare quel programma. Una routine fa o non fa eccezione, indipendentemente da ciò che pensano gli altri.

Le eccezioni e gli errori sono diversi.

Le eccezioni sono situazioni che un programma può superare, come dire che provi ad aprire un file e che 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.

L'aumento e la gestione delle eccezioni sono caratteristiche del flusso di controllo e il nome dell'eccezione dovrebbe seguire l'uso previsto. 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 per includere un meccanismo di eccezione è stato Lisp all'inizio degli anni '70. C'è un buon riassunto in Un modello di evoluzione linguistica di Gabriel e Steele . Le eccezioni (che non erano ancora chiamate eccezioni) derivavano dalla necessità di specificare il comportamento di un programma se si verifica un errore. Una possibilità è fermare il programma, ma questo non è sempre utile. Le implementazioni Lisp tradizionalmente hanno avuto modo di inserire il debugger in un 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". Originariamente gli errori venivano dalle funzioni primitive, ma i programmatori trovavano conveniente attivare un errore deliberatamente per saltare alcune parti del programma e saltare al gestore degli errori.

Nel 1972, la forma moderna di gestione delle eccezioni in Lisp apparve su MacLisp: throw e catch . Il Software Preservation Group elenca un sacco di materiale sulle prime implementazioni di Lisp, tra cui The MacLISP Reference Manual Revision 0 di David Moon . I primitivi catch e throw sono documentati in §5.3 p.43.

catch is the LISP function for doing structured non-local exits. (catch x) evaluates x and returns its values, except that if during the evaluation of x (throw y) should be evaluated, catch immediately returns y without further evaluating x.

catch may also be used with a econd argument, not evaluated, which is used as a tag to distinguish between nested catches. (…)

throw is used with catch as a structured nonlocal exit mechanism.

(throw x) evaluates x and throws the value back to the most recent catch.

(throw x <tag>) throws the value of x back to the most recent catch labelled with <tag> or unlabelled.

L'attenzione è sul flusso di controllo non locale . È una forma di goto (un goto verso l'alto), che è anche chiamato salto . La metafora è che una parte del programma getta il valore da restituire al gestore di eccezioni e il gestore di eccezioni prende quel valore e lo restituisce.

Oggi la maggior parte dei linguaggi di programmazione racchiude il tag e il valore in un oggetto di 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, eseguendo l'escape fino a quando non viene raggiunto un gestore per l'eccezione. Se una cosa del genere è considerata un "errore" nel senso intuitivo è soggettiva.

Alcune lingue fanno una distinzione tra i termini "errore" ed "eccezione". Ad esempio, alcuni dialetti Lisp hanno entrambi throw per generare un'eccezione (il flusso di controllo per gli utenti, pensato per eseguire un'uscita non locale in un modo che non indica che qualcosa è andato "sbagliato") e signal per aumentare un errore (che indica che qualcosa è andato "male" e può attivare un evento di debug).

Lo troverete interpretato in modo diverso nelle diverse implementazioni del linguaggio di programmazione. Come ha detto dasblinkenlight, è un punto di vista java avere una demarcazione tra errore ed eccezione. In molti linguaggi di programmazione le eccezioni sono violazioni che possono essere gestite o consentite per essere trasmesse per passare al modulo di codice più alto possibile. Gli errori sono generalmente situazioni in cui il contenitore del runtime della tua lingua gestisce (e in molti casi solo 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 intero "1". Un errore potrebbe essere qualcosa come l'utilizzo di un operatore non definito come "+!" nella maggior parte delle lingue.

Alcuni languges ti permetteranno di definire la tua via d'uscita se questo è davvero ciò che vuoi fare.