Argomenti a favore o contro l'utilizzo di Try / Catch come operatori logici [chiuso]

Ho appena scoperto del delizioso codice nell'app della nostra azienda che utilizza i blocchi Try-Catch come operatori logici.
Significa "esegui un codice, se questo genera questo errore, esegui questo codice, ma se ciò genera questo errore, esegui invece questa terza cosa".
Usa "Finalmente" come appare la frase "else".
So che questo è intrinsecamente sbagliato, ma prima di andare a combattere ho sperato in alcuni argomenti ben ponderati.
Ehi, se hai argomenti PER l'uso di Try-Catch in questo modo, ti preghiamo di dirlo.

Per chiunque si stia chiedendo, la lingua è C # e il codice in questione è di circa 30 righe e cerca eccezioni specifiche, non gestisce TUTTE le eccezioni.

La gestione delle eccezioni tende ad essere un modo costoso per gestire il controllo del flusso (certamente per C # e Java).

Il runtime fa un bel po 'di lavoro quando viene costruito un oggetto eccezione: mettere insieme la traccia dello stack, capire dove viene gestita l'eccezione e altro ancora.

Tutti questi costi in risorse di memoria e CPU che non necessitano di essere espansi se vengono utilizzate istruzioni di controllo del flusso per il controllo del flusso.

Inoltre, c'è un problema semantico. Le eccezioni sono per situazioni eccezionali, non per il normale controllo del flusso. Si dovrebbe usare la gestione delle eccezioni per gestire situazioni impreviste / eccezionali, non come un normale flusso di programma, perché altrimenti un'eccezione non rilevata ti dirà molto meno.

A parte questi due, c'è la questione che altri leggano il codice. L'uso delle eccezioni in questo modo non è qualcosa che la maggior parte dei programmatori si aspetta, quindi la leggibilità e la comprensibilità del tuo codice ne risentono. Quando si vede "Eccezione", si pensa: è successo qualcosa di brutto, qualcosa che non dovrebbe accadere normalmente. Quindi, usare le eccezioni in questo modo è semplicemente confuso.

Ho appena scoperto del delizioso codice nell'app della nostra azienda che utilizza i blocchi Try-Catch come operatori logici. Significa "esegui un codice, se questo genera questo errore, esegui questo codice, ma se ciò genera questo errore, esegui invece questa terza cosa". Usa "Finalmente" come appare la frase "else". So che questo è intrinsecamente sbagliato ...

Come fai a saperlo? Ho rinunciato a tutto quel tipo di "conoscenza" e ora credo solo che il codice più semplice sia il migliore. Supponiamo di voler convertire una stringa in un facoltativo che è vuoto se l'analisi non riesce. Non c'è niente di sbagliato in:

try { 
    return Optional.of(Long.valueOf(s)); 
} catch (NumberFormatException) { 
    return Optional.empty(); 
}

Sono completamente in disaccordo con la consueta interpretazione di "Le eccezioni sono per condizioni eccezionali". Quando una funzione non può restituire un valore utilizzabile o un metodo non può soddisfare le sue post-condizioni, genera un'eccezione. Non importa con quale frequenza vengono generate queste eccezioni fino a quando non si verifica un problema di prestazioni dimostrato.

Le eccezioni semplificano il codice, consentendo la separazione della gestione degli errori dal flusso normale. Scrivi semplicemente il codice più semplice possibile e, se è più facile usare try-catch o generare un'eccezione, fallo.

Le eccezioni semplificano i test riducendo il numero di percorsi attraverso il codice. Una funzione senza rami completerà o genererà un'eccezione. Una funzione con più ifistruzioni per verificare la presenza di codici di errore ha molti percorsi possibili. È molto facile sbagliare una delle condizioni o dimenticarsene completamente, in modo da ignorare alcune condizioni di errore.

Il lavoro di debug e manutenzione è molto difficile quando il flusso di controllo viene eseguito utilizzando eccezioni.

Inerentemente, le eccezioni sono progettate per essere un meccanismo per alterare il normale flusso di controllo del tuo programma - per svolgere attività insolite, causando effetti collaterali insoliti, come un modo per uscire da un legame particolarmente stretto che non può essere gestito con meno complicato si intende. Le eccezioni sono eccezionali. Ciò significa che, a seconda dell'ambiente in cui si sta lavorando, l'uso dell'eccezione per un flusso di controllo regolare può causare:

• Inefficienza I cerchi aggiuntivi che l'ambiente deve superare per eseguire in sicurezza i cambiamenti di contesto relativamente difficili richiesti per le eccezioni richiedono strumenti e risorse.

• Difficoltà di debug Talvolta informazioni utili (quando si tenta di eseguire il debug di un programma) vengono espulse dalla finestra quando si verificano eccezioni. È possibile perdere traccia dello stato o della cronologia del programma rilevanti per la comprensione del comportamento di runtime

• Problemi di manutenzione È difficile seguire il flusso di esecuzione attraverso salti di eccezione. Oltre a ciò, un'eccezione può essere generata dall'interno del codice di tipo black box, che potrebbe non comportarsi in modo facile da capire quando si genera un'eccezione.

• Cattive decisioni di progettazione I programmi costruiti in questo modo incoraggiano uno stato d'animo che, nella maggior parte dei casi, non si adatta facilmente alla risoluzione dei problemi in modo elegante. La complessità del programma finale scoraggia il programmatore dalla piena comprensione della sua esecuzione e incoraggia a prendere decisioni che portano a miglioramenti a breve termine con elevati costi a lungo termine.

Ho visto questo schema usato più volte.

Ci sono 2 problemi principali:

• È estremamente costoso (istanza dell'oggetto eccezione, raccolta dello stack di chiamate ecc.). Alcuni compilatori potrebbero effettivamente essere in grado di ottimizzarlo via, ma in questo caso non vorrei contare su questo, perché le eccezioni non sono destinate a tale uso, quindi non puoi aspettarti che le persone ottimizzino per questo.
• L'uso delle eccezioni per il flusso di controllo è in realtà un salto, molto simile a a goto. I salti sono considerati dannosi, per una serie di motivi. Dovrebbero essere utilizzati, se tutte le alternative presentano notevoli svantaggi. In effetti, in tutto il mio codice ricordo solo 2 casi, in cui i salti erano chiaramente la soluzione migliore.

A volte le eccezioni sono più veloci. Ho visto casi in cui le eccezioni agli oggetti null erano più veloci anche in Java rispetto all'uso delle strutture di controllo (al momento non posso citare lo studio, quindi dovrai fidarti di me). Il problema si presenta quando Java deve effettivamente impiegare il tempo e popolare la traccia dello stack di una classe di eccezioni personalizzata anziché utilizzare quelle native (che sembrano essere almeno parzialmente memorizzate nella cache). Prima di dire che qualcosa è unilateralmente più veloce o più lento, sarebbe bene fare un benchmark.

In Python non è solo più veloce, ma è molto più corretto fare qualcosa che potrebbe causare un'eccezione e quindi gestire l'errore. Sì, puoi applicare un sistema di tipi, ma questo va contro la filosofia della lingua - invece dovresti semplicemente provare a chiamare il metodo e catturare il risultato! (Verificare se un file è scrivibile è simile: prova a scrivere su di esso e rileva l'errore).

Ho visto volte in cui è più veloce fare qualcosa di stupido come le tabelle di query che non erano lì che capire se esiste una tabella in PHP + MySQL (la domanda in cui faccio il benchmark è in realtà la mia unica risposta accettata con voti negativi) .

Detto questo, l'uso delle eccezioni dovrebbe essere limitato per diversi motivi:

1. Deglutizione accidentale di eccezioni nidificate. Questo è importante. Se prendi un'eccezione profondamente annidata che qualcun altro sta cercando di gestire, hai appena sparato al tuo collega programmatore (forse anche a te!) Nel piede.
2. I test diventano non ovvi. Un blocco di codice che ha un'eccezione potrebbe avere una delle molte cose sbagliate. Un booleano, d'altra parte, mentre teoricamente potrebbe essere fastidioso eseguire il debug, in genere non lo è. Ciò è particolarmente vero in quanto gli try...catchaderenti al flusso di controllo generalmente (secondo la mia esperienza) non seguono la filosofia "minimizza il codice nel blocco try".
3. Non consente un else ifblocco. Ho detto abbastanza (e se qualcuno risponde con un "Ma potrebbero usare classi di eccezioni diverse", la mia risposta è "Vai nella tua stanza e non uscire finché non hai pensato a quello che hai detto.")
4. È grammaticalmente fuorviante. Exception, per il resto del mondo (come se non aderisse alla try...catchfilosofia del flusso di controllo), significa che qualcosa è entrato in uno stato instabile (sebbene forse recuperabile). Gli stati instabili sono CATTIVI e dovrebbe tenerci svegli tutti di notte se in realtà abbiamo eccezioni evitabili (in realtà mi fa impazzire, niente bugie).
5. Non è conforme allo stile di codifica comune. Il nostro lavoro, sia con il nostro codice che con la nostra interfaccia utente, è rendere il mondo il più ovvio possibile. try...catchcontrol-flow va contro quelle che sono comunemente considerate le migliori pratiche. Ciò significa che ci vuole più tempo perché qualcuno di nuovo in un progetto apprenda il progetto, il che significa un aumento del numero di ore-uomo senza alcun guadagno.
6. Ciò porta spesso alla duplicazione del codice. Infine, i blocchi, sebbene ciò non sia strettamente necessario, devono risolvere tutti i puntatori pendenti che sono stati lasciati aperti dal blocco try interrotto. Quindi prova i blocchi. Questo significa che puoi avere un try{ obj.openSomething(); /*something which causes exception*/ obj.doStuff(); obj.closeSomething();}catch(Exception e){obj.closeSomething();}. In uno if...elsescenario più tradizionale, closeSomething()è meno probabile (di nuovo, esperienza personale) essere un lavoro di copia e incolla. (Certo, questo particolare argomento ha più a che fare con le persone che ho incontrato che con la stessa filosofia).

Il mio argomento principale è che l'uso di try / catch per la logica interrompe il flusso logico. Seguire la "logica" attraverso costrutti non logici è (per me) contro-intuitivo e confuso. Sono abituato a leggere la mia logica come "if Condition then A else B". Leggere la stessa frase di "Prova A cattura quindi esegui B" sembra strano. Sarebbe ancora più strano se l'istruzione Afosse un semplice compito, richiedendo un codice aggiuntivo per forzare un'eccezione se conditionè falso (e farlo probabilmente richiederebbe ifcomunque una dichiarazione).

Bene, solo una questione di etichetta, prima di "iniziare una discussione con loro", come dici tu, chiederei gentilmente "Perché usano la gestione delle eccezioni in tutti questi diversi luoghi?"

Voglio dire, ci sono diverse possibilità:

1. sono incompetenti
2. c'è una ragione perfettamente valida per quello che hanno fatto, che potrebbe non apparire a prima vista.
3. a volte è una questione di gusti e può semplificare un flusso di programma complesso.
4. È una reliquia del passato che nessuno è ancora cambiato e sarebbero felici se qualcuno lo facesse

... Penso che tutti questi siano ugualmente probabili. Quindi basta chiedere loro bene.

Try Catch deve essere utilizzato solo per la gestione delle eccezioni. Inoltre, gestione delle eccezioni specifica. Il tuo tentativo di cattura dovrebbe catturare solo le eccezioni previste, altrimenti non è ben formato. Se hai bisogno di usare una cattura, prova a catturare, probabilmente stai facendo qualcosa di sbagliato.

MODIFICARE:

Motivo: si può sostenere che se si utilizza try catch come operatore condizionale, in che modo verranno considerate le eccezioni REALI?

Le eccezioni sono per quando succedono cose eccezionali. Il programma funziona secondo un flusso di lavoro regolare eccezionale?

Motivo per utilizzare le eccezioni:

1. Se dimentichi di cogliere una circostanza eccezionale, il tuo programma morirà e la traccia dello stack ti dirà esattamente perché. Se si dimentica di gestire il valore restituito per una circostanza di eccezione, non è possibile stabilire fino a che punto il programma presenterà un comportamento errato.
2. L'uso dei valori di ritorno funziona solo se è possibile restituire un valore sentinella. Se tutti i possibili valori di ritorno sono già validi, cosa hai intenzione di fare?
3. Un'eccezione porterà ulteriori informazioni su ciò che è accaduto che potrebbero essere utili.

Motivi per non utilizzare le eccezioni:

1. Molte lingue non sono progettate per rendere veloci le eccezioni.
2. Le eccezioni che viaggiano su più livelli nella pila possono lasciare uno stato incoerente sulla loro scia

Alla fine:

L'obiettivo è scrivere codice che comunichi ciò che sta succedendo. Le eccezioni possono aiutare / ostacolare ciò a seconda di cosa sta facendo il codice. Un tentativo / cattura in Python per un KeyError su un riferimento del dizionario è perfettamente (fintanto che conosci la lingua) provare / catturare per lo stesso KeyError a cinque livelli di funzione è pericoloso.

Uso try-> catch come controllo di flusso in determinate situazioni. Se la tua logica primaria dipende da qualcosa che fallisce, ma non vuoi semplicemente lanciare un'eccezione ed uscire ... Ecco a cosa serve un blocco try-> catch. Scrivo molti script unix lato server non monitorati, ed è molto più importante per loro non fallire, di quanto non lo sia per loro graziosamente.

Quindi prova il piano A, e se il piano A muore, prendi e corri con il piano B ... E se il piano B fallisce, usa infine per dare il via al piano C, che risolverà uno dei servizi falliti in A o B, oppure pagina me.

Dipende dalla lingua e forse dall'implementazione utilizzata. Lo standard in C ++ è che le eccezioni dovrebbero essere salvate per eventi davvero eccezionali. D'altra parte, in Python una delle linee guida è " è più facile chiedere perdono che autorizzazione ", quindi è incoraggiata l'integrazione di try / tranne blocchi nella logica del programma.

È una cattiva abitudine, ma lo faccio di tanto in tanto in Python. Come invece di verificare se esiste un file, provo solo a eliminarlo. Se genera un'eccezione, prendo e vado avanti sapendo che non c'era. <== (non necessariamente vero se un altro utente possiede il file, ma lo faccio nella home directory di un utente in modo che NON DOVREBBE accadere).

Tuttavia, abusato è una cattiva pratica.

Mi piace il modo in cui Apple lo definisce : le eccezioni sono solo per errori del programmatore e errori fatali di runtime. Altrimenti usa i codici di errore. Mi aiuta a decidere quando usarlo, pensando a me stesso "È stato un errore del programmatore?"

Sembra come usare la gestione delle eccezioni per costruire la logica goto su una lingua che non ha un comando goto.

Per i molti motivi per cui la logica goto è errata, puoi fare riferimento a questa domanda: https://stackoverflow.com/questions/46586/goto-still-considered-harmful