L'eccezione gestisce un problema trasversale?

12

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

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

Ad esempio, una lingua può 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 di cui sopra, il programma non compilerà in assenza di FileReader gestore , perché il file di lettura FileReader classe non sta lanciando l'eccezione. Quindi, dichiarando il FileReader handler , il compilatore può garantire che sia gestito e il programma quindi compila.

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

    
posta Behrang 09.08.2011 - 06:46
fonte

4 risposte

13

In alcuni casi sì

Nei casi in cui si dispone di un'eccezione che si desidera registrare (che presumibilmente sarà quasi sempre), allora l'eccezione è legata a una preoccupazione trasversale.

La maggior parte 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 previsto e quindi l'applicazione dovrebbe agire in base alle circostanze che hanno causato l'eccezione. Questo non è qualcosa che un Aspect generico dovrebbe gestire, e quindi non dovrebbe essere una preoccupazione trasversale.

Identificazione di una preoccupazione trasversale

Se si duplica lo stesso codice più e più volte deve essere astratto. Se l'astrazione si promuove su più livelli, potrebbe essere una preoccupazione trasversale. Solo allora dovrebbe essere considerato.

    
risposta data 09.08.2011 - 08:09
fonte
4

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

La registrazione è piuttosto generica e, mentre proviene da una logica specifica, si nutre di un consumatore generico. Le eccezioni sono sempre specifiche per la logica e alcuni codici sono ben informati su quella logica che deve gestire il disordine che ha fatto.

Almeno nel mio uso limitato dei due ciò significa che i due obiettivi sono gestiti meglio in modi diversi e non sotto lo stesso schema di progettazione.

    
risposta data 09.08.2011 - 08:01
fonte
1

Considero la gestione delle eccezioni come una preoccupazione trasversale per determinati tipi di eccezioni. Esistono eccezioni locali che solo il codice chiamante immediato può gestire correttamente. Un esempio potrebbe essere un'eccezione del database quando si tenta di eseguire una query. Ma ci sono anche eccezioni che possono e devono essere gestite più globalmente. Un esempio potrebbe essere un'eccezione legata alla mancanza di credenziali di sicurezza (obbliga l'utente ad accedere di nuovo). O per lo meno hai bisogno di un gestore globale nel caso in cui un'eccezione scivoli attraverso il codice più specifico, per spiegare all'utente cosa dovrebbero fare per riavviare o inviare un log all'IT o qualcosa del genere. Per questi tipi di eccezioni gestite globalmente, è una preoccupazione trasversale.

    
risposta data 09.08.2011 - 13:50
fonte
0

Penso che questo si colleghi al problema delle astrazioni che perdono.

Numerose eccezioni dovrebbero essere catturate e riconvertite mentre si propagano attraverso gli strati di 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 livelli più alti di astrazione non abbiano bisogno di conoscere i livelli inferiori, anche puramente 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 abbiano senso per un'astrazione di "file" o, in caso affermativo, che l'astrazione non abbia realmente completamente sradicato tutti i dettagli relativi all'implementazione della gestione dei file.

Un errore di rete verrebbe quindi a discostarsi dall'astrazione di rete sottostante e, pertanto, deve essere un problema trasversale all'interno del 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 del file, ma che invece descrivono il disco rigido o la rete o qualsiasi errore sono la stessa cosa in una forma diversa, implicando i guasti del disco rigido e gli errori di rete ecc. sono preoccupazioni trasversali a prescindere dal modo in cui tali guasti sono segnalati.

    
risposta data 10.08.2011 - 03:28
fonte

Leggi altre domande sui tag