Le eccezioni di resume hanno senso?

Non direttamente correlato a Scala, ma quando veniva progettato il meccanismo di eccezione C ++, c'erano grossi argomenti sulla ripresa. Alla fine, hanno esaminato una base di codice molto ampia (non di C ++) in cui la ripresa potrebbe essere stata utilizzata e ha trovato solo una sua istanza, che potrebbe essere facilmente riscritta per non usarla. Inoltre, i membri del comitato del C ++ che avevano usato la ripresa erano fermamente convinti che non causasse altro che problemi. Quindi è stato deciso che C ++ non dovrebbe supportare la ripresa delle eccezioni. I designer della maggior parte delle altre lingue sembrano essere della stessa opinione.

Il vero punto di eccezione riassumibile è che il luogo in cui si verifica l'eccezione spesso non è il posto giusto per decidere cosa fare al riguardo. L'eccezione di directory mancante dell'OP può verificarsi all'interno di una libreria di utilità di basso livello, che può essere utilizzata da molti sistemi diversi.

Se il codice client è un programma batch, potrebbe non esserci nulla di meglio da fare che pulire, registrare l'errore e morire. Tuttavia, se l'errore si verifica in un'applicazione interattiva, è perfettamente logico chiedere all'utente di creare la directory o specificarne una alternativa e continuare. Non vuoi che la libreria di utilità sappia sui diversi modi di gestire la directory mancante e lanciare un'eccezione ordinaria perde il tuo attuale contesto / stato.

Con le eccezioni ripristinabili (o una continuazione) puoi consentire al codice client di decidere cosa fare sulla directory mancante con l'opzione di riprendere da dove si è verificato l'errore, possibilmente utilizzando una directory diversa.

La libreria di utilità lancia solo un'eccezione di resume (o un'eccezione contenente la continuazione corrente) senza alcun accoppiamento su come il problema possa essere risolto.

Credo che le eccezioni di resume siano più utili nelle piattaforme linguistiche in cui è possibile rilevare un'eccezione, utilizzare il debugger per isolare il problema, modificare il codice per risolvere il problema e aggiornare il sistema in esecuzione con il nuovo codice prima di riprendere il programma. Pensa alla Lisp Machine e forse a Smalltalk. I sistemi moderni si sono allontanati da quel livello di interattività; Non ho mai usato un sistema del genere (ad eccezione di emacs, ma sono un utente di emacs superficiale), quindi prendi la mia risposta con un pizzico di sale.

Si noti che le continuazioni ripristinabili sono simili alle continuazioni, che hanno altri usi a sé stanti.

Un framework web Smalltalk "Seaside" utilizza le aspettative di ripresa.

Il guadagno: puoi scrivere il codice che segue gli utenti che camminano attraverso le pagine web (chiede e riprende).

L'alternativa (con framework e linguaggi web comuni che non supportano le eccezioni di ripristino) consiste nel suddividere il codice in blocchi e stato di sessione piccoli, non correlati.