La gestione delle eccezioni è una preoccupazione trasversale?

Non vedo molta differenza tra le preoccupazioni relative alla gestione delle eccezioni e l'accesso in quanto entrambe sono preoccupazioni trasversali. Cosa pensi? Non dovrebbe essere gestito separatamente da solo piuttosto che intercalato con la logica di base che un metodo sta implementando?

EDIT : Quello che sto cercando di dire è che a mio avviso l'implementazione di un metodo dovrebbe contenere solo la logica per il successo del percorso di esecuzione e le eccezioni dovrebbero essere gestite altrove. Non si tratta di eccezioni verificate / non selezionate.

Ad esempio, una lingua potrebbe gestire le eccezioni in modo completamente controllato usando costrutti come questo:

class FileReader {

  public String readFile(String path) {
    // implement the reading logic, avoid exception handling
  }

}

handler FileReader {

   handle String readFile(String path) {
      when (IOException joe) {
        // somehow access the FileInputStram and close it
      }
   }

}

Nel linguaggio concettuale sopra, il programma non verrà compilato in assenza del FileReader gestore , poiché il file readFile della FileReader classe non genera l'eccezione. Pertanto, dichiarando il FileReader gestore , il compilatore può assicurarsi che venga gestito e che quindi il programma venga compilato.

In questo modo abbiamo il meglio dei problemi di eccezione controllati e non controllati: robustezza e leggibilità.

In alcuni casi sì

Nei casi in cui si ha un'eccezione che si desidera registrare (che suppongo sia quasi sempre), sì, l'eccezione è legata a una preoccupazione trasversale.

Il più delle volte no

Tuttavia, prendi l'istanza di un SocketListener, se un socketlistener genera un'eccezione a causa dell'altra estremità che interrompe la connessione, allora questo dovrebbe essere un comportamento anticipato e quindi l'applicazione dovrebbe agire in base alle circostanze che hanno causato l'eccezione. Questo non è qualcosa che un aspetto generico dovrebbe gestire, e quindi non dovrebbe essere una preoccupazione trasversale.

Individuare una preoccupazione trasversale

Se si duplica ripetutamente lo stesso codice, è necessario estrarlo. Se l'astrazione si promuove su più livelli, potrebbe essere una preoccupazione trasversale. Solo allora dovrebbe essere considerato.

La registrazione è facoltativa. Gestire le eccezioni non lo è.

La registrazione è piuttosto generica e, sebbene provenga da una logica specifica, si nutre di un consumatore generico. Le eccezioni sono sempre specifiche della logica e alcuni codici informati su tale logica devono gestire il disordine che ha creato.

Almeno nel mio uso limitato dei due ciò significa che i due obiettivi vengono gestiti al meglio in modi diversi e non sotto lo stesso design.

Considero la gestione delle eccezioni una preoccupazione trasversale per alcuni tipi di eccezioni. Esistono eccezioni locali che solo il codice di chiamata immediata può gestire correttamente. Un esempio potrebbe essere un'eccezione del database quando si tenta di eseguire una query. Ma ci sono anche delle eccezioni che possono e dovrebbero essere gestite in modo più globale. Un esempio potrebbe essere un'eccezione correlata alla mancanza di credenziali di sicurezza (forzare l'utente ad accedere nuovamente). O almeno hai bisogno di un gestore globale nel caso in cui un'eccezione passi attraverso il codice più specifico, per spiegare all'utente cosa dovrebbero fare per riavviare o inviare un registro all'IT o qualcosa del genere. Per questi tipi di eccezioni gestite a livello globale, si tratta di una preoccupazione trasversale.

Penso che questo sia in relazione con la questione delle astrazioni che perdono.

Molte eccezioni dovrebbero essere catturate e riproposte mentre si propagano attraverso gli strati dell'astrazione. Il rilancio dovrebbe gettare l'eccezione in una nuova forma, appropriata all'astrazione che sta facendo il rilancio, in modo che abbia senso come parte dell'interfaccia. In altre parole, le eccezioni dai livelli più bassi di astrazione dovrebbero essere tradotte in forma di astrazione corrente in modo che i livelli più alti di astrazione non debbano conoscere i livelli inferiori, anche solo per la gestione delle eccezioni.

Tuttavia, il "principio delle astrazioni che perdono" è un problema. Alcune eccezioni non possono essere tradotte in una forma che abbia senso all'interno del prossimo livello di astrazione.

Un'eccezione relativa al filesystem in rete è un semplice esempio. Un errore di rete non può essere espresso in termini che hanno senso per un'astrazione "file" o, in caso affermativo, tale astrazione non ha davvero completamente sottratto tutti i dettagli relativi all'implementazione della gestione dei file.

Un errore di rete dovrebbe pertanto fuoriuscire dall'astrazione di rete sottostante e deve pertanto costituire una preoccupazione trasversale nel resto del codice.

Questo non è unico per le eccezioni, però. Tutti quei codici di errore del valore restituito per le API dei file che non sono realmente correlati all'astrazione dei file, ma descrivono invece i dettagli del disco rigido o della rete o qualsiasi errore sia lo stesso in una forma diversa, il che implica che i guasti del disco rigido e quelli della rete ecc. sono preoccupazioni trasversali indipendentemente dal modo in cui tali guasti vengono segnalati.