Come gestire le eccezioni degli ascoltatori licenziati

Question

Come gestire le eccezioni degli ascoltatori licenziati

Naviga le tue risposte

#1 da (7 voti)
#2 da (1 voti)

5

Questa è più una domanda di design e speravo di ottenere pro e opinioni su ciò che ha senso.

SFONDO

Immagina qualcosa che contenga uno o più ascoltatori di eventi. Ogni tanto la cosa lancia eventi ai suoi ascoltatori.

PROBLEMA

Il problema è ovviamente che gli ascoltatori che seguono dopo un ascoltatore che non hanno mai avuto occasione di conoscere l'evento. Questo significa che l'ordine degli ascoltatori è quindi un problema.

SOLUZIONE # 1

Esegui tutti gli ascoltatori che ricevono eccezioni generate. Ciò significa che tutti gli ascoltatori vengono licenziati ma di per sé presentano altri problemi.

Cosa si dovrebbe fare con le eccezioni intercettate?

Un'opzione è catturarli tutti e dopo aver sparato a tutti gli eventi lancia un'altra eccezione che contiene tutti i problemi. ++
L'altra opzione è di accedere ~~
L'ultimo è semplicemente ignorare queste eccezioni. -
Gli ascoltatori vengono eseguiti in isolamento, il che è positivo. ++

SOLUZIONE # 2

Questa opzione è semplicistica e consente semplicemente a qualsiasi eccezione generata di uscire da un ascoltatore, con il risultato che gli ascoltatori rimanenti non vengono mai licenziati. I problemi con questo approccio significano che

l'ordine degli ascoltatori è significativo (-)
semplice da implementare (+).
prima che gli ascoltatori possano influenzare il chiamante

Q

Quale approccio ha senso e causa il minor numero di problemi. Ha davvero senso isolare gli ascoltatori in modo che ottengano gli eventi ma non possono causare l'interruzione di un'operazione in esecuzione se si lanciano?

design-patterns exceptions

posta mP01 12.09.2011 - 07:30

fonte

2 risposte

1

Di solito la fonte dell'evento (osservabile) è disaccoppiata dagli osservatori. Quindi il design è qualcosa di seguito:

Observable -> (fires)-> Observer1,Observer2,Observer3...ObserverN

Tuttavia, se è necessario aggiungere una logica aggiuntiva, aggiungere un altro riferimento indiretto usando una classe ObserserProcessor.

Observable -> (fires)
           |->ObserverProcessor1-->(log each)--> Observer1 ... Observer9
           |->ObserverProcessor2-->(whatever)-->Observer10 ... Observer20

In questo modo la tua logica di osservatori è ancora disaccoppiata dalla classe osservabile ma raggruppata in modo che tu possa aggiungere ulteriore logica di elaborazione nel mezzo.

Spero che questo aiuti.

risposta data 12.09.2011 - 09:24

fonte

Leggi altre domande sui tag design-patterns exceptions

Differenza tra statechart e diagramma di sequenza Accesso ai dati per applicazioni componibili

score 7 · Accepted Answer

Un paio di punti da considerare:

Gli ascoltatori dovrebbero essere ben educati in quanto proteggono l'esecuzione del proprio codice impedendo l'uscita di eccezioni all'esterno.

L'event firer (?), che è quello che ha sparato l'evento, non ha (dovrebbe avere) alcun interesse per ciò che gli ascoltatori fanno con esso. Il suo unico compito è garantire che tutti gli ascoltatori possano ascoltare l'evento. Ciò significa che dovrebbe proteggere contro uno degli ascoltatori che fa qualcosa che impedirebbe ad altri ascoltatori di ottenere l'evento. Quindi, sì, prendi le eccezioni.

L'evento non ha interesse a catturare eccezioni se non per assicurare che un comportamento scorretto da parte di un ascoltatore non influisca su altri ascoltatori. Quindi in questo caso "mangiare" si potrebbe sostenere l'eccezione. Tuttavia, mangiare eccezioni non aiuta nessuno, quindi registrare l'eccezione con il maggior numero possibile di dettagli sul listener offensivo è la strada da percorrere.

Non vorrei che il licenziatario raccolga eccezioni e alla fine ne aumenti di propria iniziativa. Semplicemente perché il licenziatario ha fatto il suo lavoro correttamente e non ha bisogno di lanciare un'eccezione. Registrando le eccezioni generate da ascoltatori che si comportano male, il licenziatore sta già facendo la sua parte per facilitare il debugging necessario. (I log dovrebbero sempre essere esenti da eccezioni ...).