Alla fine degli anni '90 ho lavorato parecchio con una base di codice che utilizzava le eccezioni come controllo di flusso. Ha implementato una macchina a stati finiti per gestire le applicazioni di telefonia. Ultimamente mi vengono in mente quei giorni perché ho fatto app Web MVC.

Entrambi hanno Controllers che decidono dove andare dopo e forniscono i dati alla logica di destinazione. Le azioni dell'utente dal dominio di un telefono di vecchia scuola, come i toni DTMF, sono diventate parametri dei metodi di azione, ma invece di restituire qualcosa di simile a ViewResult, hanno lanciato a StateTransitionException.

Penso che la differenza principale fosse che i metodi di azione erano voidfunzioni. Non ricordo tutte le cose che ho fatto con questo fatto, ma sono stato titubante anche solo a ricordare molto perché da quel lavoro, come 15 anni fa, non l'ho mai visto nel codice di produzione in nessun altro lavoro . Ho pensato che questo fosse un segno che era un cosiddetto anti-schema.

È questo il caso e, in caso affermativo, perché?

Aggiornamento: quando ho posto la domanda, avevo già in mente la risposta di @ MasonWheeler, quindi sono andato con la risposta che ha aggiunto di più alla mia conoscenza. Penso che anche la sua sia una risposta valida.

C'è una discussione dettagliata di questo sul Wiki di Ward . In generale, l'uso di eccezioni per il controllo di flusso è un anti-modello, con molte notevoli situazione - e il linguaggio specifico (si veda ad esempio, Python ) tosse eccezioni tosse .

Come una breve sintesi del perché, generalmente, è un anti-pattern:

• Le eccezioni sono, in sostanza, sofisticate dichiarazioni GOTO
• La programmazione con eccezioni, quindi, rende più difficile leggere e comprendere il codice
• La maggior parte delle lingue ha strutture di controllo esistenti progettate per risolvere i tuoi problemi senza l'uso di eccezioni
• Gli argomenti per l'efficienza tendono ad essere discutibili per i compilatori moderni, che tendono ad ottimizzare ipotizzando che le eccezioni non vengano utilizzate per il flusso di controllo.

Leggi la discussione sul wiki di Ward per informazioni molto più approfondite.

Vedi anche un duplicato di questa domanda, qui

Il caso d'uso per cui sono state progettate le eccezioni è "Ho appena incontrato una situazione che non posso affrontare correttamente a questo punto, perché non ho abbastanza contesto per gestirlo, ma la routine che mi ha chiamato (o qualcosa di più lungo la chiamata stack) dovrebbe sapere come gestirlo ".

Il caso d'uso secondario è "Ho appena riscontrato un errore grave e in questo momento uscire da questo flusso di controllo per prevenire la corruzione dei dati o altri danni è più importante che cercare di continuare".

Se non stai usando le eccezioni per uno di questi due motivi, probabilmente c'è un modo migliore per farlo.

Le eccezioni sono potenti come Continuations e GOTO. Sono un costrutto di flusso di controllo universale.

In alcune lingue, sono l' unico costrutto del flusso di controllo universale. JavaScript, ad esempio, non ha né Continuazioni né GOTO, neppure ha chiamate di coda adeguate. Pertanto, se si desidera implementare un flusso di controllo sofisticato in JavaScript, è necessario utilizzare Eccezioni.

Il progetto Microsoft Volta era un progetto di ricerca (ora fuori produzione) per compilare codice .NET arbitrario in JavaScript. .NET ha Eccezioni la cui semantica non si associa esattamente a JavaScript, ma, soprattutto, ha Thread , e devi mapparli in qualche modo su JavaScript. Volta ha fatto questo implementando Continuazioni Volta usando JavaScript Exceptions e quindi implementando tutti i costrutti del flusso di controllo .NET in termini di Continuazioni Volta. Hanno dovuto usare le eccezioni come flusso di controllo, perché non esiste un altro costrutto di flusso di controllo abbastanza potente.

Hai menzionato le macchine statali. Gli SM sono banali da implementare con le chiamate di coda appropriate: ogni stato è una subroutine, ogni transizione di stato è una chiamata di subroutine. Gli SM possono anche essere facilmente implementati con GOTOo Coroutine o Continuazioni. Tuttavia, Java non ha nessuno di questi quattro, ma ha ha eccezioni. Quindi, è perfettamente accettabile usare quelli come flusso di controllo. (Beh, in realtà, la scelta corretta sarebbe probabilmente quella di usare un linguaggio con il costrutto del flusso di controllo corretto, ma a volte potresti rimanere bloccato con Java.)

Come altri hanno già detto numerose volte ( ad esempio in questa domanda di Stack Overflow ), il principio del minimo stupore vieta l'uso eccessivo delle eccezioni solo per scopi di controllo del flusso. D'altra parte, nessuna regola è corretta al 100% e ci sono sempre quei casi in cui un'eccezione è "lo strumento giusto" - molto simile a gotose stessa, a proposito, che viene fornita sotto forma di breake continuein linguaggi come Java, che sono spesso il modo perfetto per saltare da anelli pesantemente annidati, che non sono sempre evitabili.

Il seguente post sul blog spiega un caso d'uso piuttosto complesso ma anche piuttosto interessante per un non locale ControlFlowException :

• http://blog.jooq.org/2013/04/28/rare-uses-of-a-controlflowexception

Spiega come all'interno di jOOQ (una libreria di astrazione SQL per Java) (dichiarazione di non responsabilità: lavoro per il fornitore), tali eccezioni vengono occasionalmente utilizzate per interrompere presto il processo di rendering SQL quando viene soddisfatta una condizione "rara".

Esempi di tali condizioni sono:

• Sono stati rilevati troppi valori di bind. Alcuni database non supportano numeri arbitrari di valori di bind nelle loro istruzioni SQL (SQLite: 999, Ingres 10.1.0: 1024, Sybase ASE 15.5: 2000, SQL Server 2008: 2100). In questi casi, jOOQ interrompe la fase di rendering SQL e esegue nuovamente il rendering dell'istruzione SQL con valori di bind incorporati. Esempio:

  // Pseudo-code attaching a "handler" that will
  // abort query rendering once the maximum number
  // of bind values was exceeded:
  context.attachBindValueCounter();
  String sql;
  try {
  
    // In most cases, this will succeed:
    sql = query.render();
  }
  catch (ReRenderWithInlinedVariables e) {
    sql = query.renderWithInlinedBindValues();
  }
  

  Se estraessimo esplicitamente i valori di bind dalla query AST per contarli ogni volta, sprecheremmo preziosi cicli della CPU per il 99,9% delle query che non soffrono di questo problema.

• Alcune logiche sono disponibili solo indirettamente tramite un'API che vogliamo eseguire solo "parzialmente". Il UpdatableRecord.store()metodo genera un'istruzione INSERTo UPDATE, a seconda Recorddei flag interni del. Dall'esterno, non sappiamo in quale tipo di logica sia contenuta store()(ad es. Blocco ottimistico, gestione del listener di eventi, ecc.), Quindi non vogliamo ripetere quella logica quando memorizziamo diversi record in un'istruzione batch, dove vorremmo store()solo generare l'istruzione SQL, non effettivamente eseguirla. Esempio:

  // Pseudo-code attaching a "handler" that will
  // prevent query execution and throw exceptions
  // instead:
  context.attachQueryCollector();
  
  // Collect the SQL for every store operation
  for (int i = 0; i < records.length; i++) {
    try {
      records[i].store();
    }
  
    // The attached handler will result in this
    // exception being thrown rather than actually
    // storing records to the database
    catch (QueryCollectorException e) {
  
      // The exception is thrown after the rendered
      // SQL statement is available
      queries.add(e.query());                
    }
  }
  

  Se avessimo esternalizzato la store()logica in API "riutilizzabili" che possono essere personalizzate per facoltativamente non eseguire l'SQL, cercheremmo di creare un'API piuttosto difficile da mantenere, difficilmente riutilizzabile.

Conclusione

In sostanza, il nostro uso di questi non locali gotoè proprio in linea con quanto affermato da Mason Wheeler nella sua risposta:

"Ho appena incontrato una situazione che non posso affrontare correttamente a questo punto, perché non ho abbastanza contesto per gestirlo, ma la routine che mi ha chiamato (o qualcosa più in alto nello stack di chiamate) dovrebbe sapere come gestirlo ".

Entrambi gli usi di ControlFlowExceptionserano piuttosto facili da implementare rispetto alle loro alternative, permettendoci di riutilizzare una vasta gamma di logiche senza refactoring dai relativi interni.

Ma la sensazione di essere un po 'una sorpresa per i futuri manutentori rimane. Il codice sembra piuttosto delicato e, sebbene in questo caso sia stata la scelta giusta, preferiremmo sempre non utilizzare le eccezioni per il flusso di controllo locale , dove è facile evitare l'uso di diramazioni ordinarie if - else.

L'uso delle eccezioni per il flusso di controllo è generalmente considerato un anti-pattern, ma ci sono eccezioni (nessun gioco di parole previsto).

È stato detto mille volte che le eccezioni sono pensate per condizioni eccezionali. Una connessione al database interrotta è una condizione eccezionale. Un utente che inserisce lettere in un campo di input che dovrebbe consentire solo numeri non lo è .

Un bug nel tuo software che provoca la chiamata di una funzione con argomenti illegali, ad esempio nulldove non lo consente, è una condizione eccezionale.

Usando le eccezioni per qualcosa che non è eccezionale, stai usando astrazioni inadeguate per il problema che stai cercando di risolvere.

Ma può esserci anche una penalità per le prestazioni. Alcune lingue hanno un'implementazione della gestione delle eccezioni più o meno efficiente, quindi se la tua lingua preferita non ha una gestione efficiente delle eccezioni, può essere molto costosa, dal punto di vista delle prestazioni *.

Ma altre lingue, ad esempio Ruby, hanno una sintassi simile all'eccezione per il flusso di controllo. Situazioni eccezionali sono gestite dagli operatori raise/ rescue. Ma puoi usare throw/ catchper costrutti di flusso di controllo simili a eccezioni **.

Pertanto, sebbene le eccezioni non vengano generalmente utilizzate per il flusso di controllo, la lingua scelta può avere altri modi di dire.

* Nell'esempio di un uso costoso delle eccezioni in termini di prestazioni: una volta mi ero prefissato di ottimizzare un'applicazione ASP.NET Web Form con prestazioni scadenti. Si è scoperto che il rendering di un grande tavolo stava chiamando int.Parse()circa. mille stringhe vuote su una pagina media, risultando in ca. mille eccezioni vengono gestite. Sostituendo il codice con int.TryParse()mi sono rasato un secondo! Per ogni singola richiesta di pagina!

** Questo può essere molto confusa per un programmatore venire a Ruby da altre lingue, sia come throwe catchsono parole chiave associate con le eccezioni in molte altre lingue.

È completamente possibile gestire le condizioni di errore senza l'uso di eccezioni. Alcune lingue, in particolare C, non hanno nemmeno eccezioni e le persone riescono comunque a creare applicazioni piuttosto complesse. Il motivo per cui le eccezioni sono utili è che consentono di specificare in modo succinto due flussi di controllo essenzialmente indipendenti nello stesso codice: uno in caso di errore e uno in caso contrario. Senza di essi, si finisce con il codice in tutto il posto che assomiglia a questo:

status = getValue(&inout);
if (status < 0)
{
    logError("message");
    return status;
}

doSomething(*inout);

O equivalente nella tua lingua, come restituire una tupla con un valore come stato di errore, ecc. Spesso le persone che sottolineano quanto sia "costosa" la gestione delle eccezioni, trascurano tutte le ifdichiarazioni extra come quelle sopra che devi aggiungere se non utilizzare eccezioni.

Sebbene questo schema si verifichi più spesso quando si gestiscono errori o altre "condizioni eccezionali", a mio avviso se si inizia a vedere il codice del boilerplate come questo in altre circostanze, si ha un buon argomento per usare le eccezioni. A seconda della situazione e dell'implementazione, posso vedere le eccezioni utilizzate validamente in una macchina a stati, perché hai due flussi di controllo ortogonali: uno che sta cambiando lo stato e uno per gli eventi che si verificano all'interno degli stati.

Tuttavia, quelle situazioni sono rare e se hai intenzione di fare un'eccezione (gioco di parole intenzionale) alla regola, è meglio essere preparati a mostrare la sua superiorità ad altre soluzioni. Una deviazione senza tale giustificazione è giustamente chiamata anti-schema.

In Python, le eccezioni vengono utilizzate per la terminazione del generatore e dell'iterazione. Python ha dei tentativi / blocchi molto efficienti, ma in realtà sollevare un'eccezione ha un certo sovraccarico.

A causa della mancanza di interruzioni multilivello o di un'istruzione goto in Python, a volte ho usato le eccezioni:

class GOTO(Exception):
  pass

try:
  # Do lots of stuff
  # in here with multiple exit points
  # each exit point does a "raise GOTO()"
except GOTO:
  pass
except Exception as e:
  #display error

Facciamo uno schizzo di tale utilizzo delle eccezioni:

L'algoritmo cerca ricorsivamente fino a quando non viene trovato qualcosa. Quindi, tornando dalla ricorsione, si deve controllare il risultato per essere trovato, e poi tornare, altrimenti continuare. E questo torna ripetutamente da una certa profondità di ricorsione.

Oltre alla necessità di un valore booleano aggiuntivo found(da impacchettare in una classe, dove altrimenti sarebbe stato restituito solo un int), e per la profondità di ricorsione si verifica lo stesso postlude.

Un tale svolgimento di uno stack di chiamate è proprio ciò a cui fa eccezione. Quindi mi sembra un mezzo di programmazione non simil-goto, più immediato e appropriato. Non necessario, uso raro, forse cattivo stile, ma al punto. Paragonabile all'operazione di taglio Prolog.

La programmazione riguarda il lavoro

Penso che il modo più semplice per rispondere a questo sia capire i progressi che OOP ha fatto nel corso degli anni. Tutto ciò che viene fatto in OOP (e la maggior parte dei paradigmi di programmazione, per quella materia) è modellato sulla necessità di lavorare .

Ogni volta che viene chiamato un metodo, il chiamante dice "Non so come fare questo lavoro, ma tu sai come, quindi lo fai per me".

Ciò presentava una difficoltà: cosa succede quando il metodo chiamato generalmente sa come fare il lavoro, ma non sempre? Avevamo bisogno di un modo per comunicare "Volevo aiutarti, davvero, ma non posso proprio farlo."

Una metodologia iniziale per comunicare ciò consisteva semplicemente nel restituire un valore "immondizia". Forse ti aspetti un numero intero positivo, quindi il metodo chiamato restituisce un numero negativo. Un altro modo per ottenere ciò era impostare un valore di errore da qualche parte. Sfortunatamente, in entrambi i modi il codice kosher mi ha permesso di controllare qui tutto per assicurarmi di controllare tutto . Man mano che le cose diventano più complicate, questo sistema cade a pezzi.

Un'analogia eccezionale

Supponiamo che tu abbia un falegname, un idraulico e un elettricista. Vuoi un idraulico per sistemare il lavandino, quindi lui lo guarda. Non è molto utile se dice solo a te: "Mi dispiace, non posso ripararlo. È rotto." Diavolo, è ancora peggio se dovesse dare un'occhiata, andarsene e spedirti una lettera dicendo che non poteva aggiustarlo. Ora devi controllare la tua posta prima ancora di sapere che non ha fatto quello che volevi.

Quello che preferiresti è che ti dica "Guarda, non sono riuscito a ripararlo perché sembra che la tua pompa non funzioni".

Con queste informazioni, puoi concludere che desideri che l'elettricista dia un'occhiata al problema. Forse l'elettricista troverà qualcosa di simile al carpentiere e dovrai far riparare il carpentiere.

Cavolo, potresti non sapere nemmeno di aver bisogno di un elettricista, potresti non sapere di chi hai bisogno. Sei solo un intermediario in un'impresa di riparazioni domestiche e la tua attenzione è l'idraulica. Quindi dite Non Sei capo del problema, e poi si dice l'elettricista per risolvere il problema.

Questo è ciò che le eccezioni stanno modellando: modalità di fallimento complesse in modo disaccoppiato. L'idraulico non ha bisogno di sapere dell'elettricista, non ha nemmeno bisogno di sapere che qualcuno nella catena può risolvere il problema. Riferisce solo sul problema che ha riscontrato.

Quindi ... un anti-pattern?

Ok, quindi capire il punto delle eccezioni è il primo passo. Il prossimo è capire cos'è un anti-pattern.

Per qualificarsi come anti-modello, è necessario

• risolvere il problema
• hanno conseguenze decisamente negative

Il primo punto è facilmente soddisfatto: il sistema ha funzionato, giusto?

Il secondo punto è più appiccicoso. Il motivo principale per l'utilizzo delle eccezioni come flusso di controllo normale è negativo perché non è questo il loro scopo. Ogni data funzionalità di un programma dovrebbe avere uno scopo relativamente chiaro e la cooptazione di tale scopo porta a una confusione non necessaria.

Ma questo non è un danno definitivo . È un modo scarso di fare le cose, e strano, ma un anti-schema? No. Solo ... strano.