Come evitare eccezioni catture copia-incolla in .NET

Question

Lavorare con .NET framework Ho un servizio con una serie di metodi che possono genera diversi tipi di eccezioni: MyException2, MyExc1, Exception ... Fornire lavoro adeguata per tutti metodi, ciascuno dei quali contiene le seguenti sezioni:

[WebMethod] 
void Method1(...) 
{ 
    try 
    { 
     ... required functionality 
    } 
    catch(MyException2 exc) 
    { 
     ... process exception of MyException2 type 
    } 
    catch(MyExc1 exc) 
    { 
     ... process exception of MyExc1 type 
    } 
    catch(Exception exc) 
    { 
     ... process exception of Exception type 
    } 
    ... process and return result if necessary 
} 

E 'molto noioso per avere esattamente stesse cose in ogni metodo di servizio (ogni metodo ha diversi set di parametri) esattamente stesse eccezioni funzionalità di elaborazione ...

Esiste la possibilità di "raggruppare" queste sezioni di cattura e utilizzare solo una linea (qualcosa di simile alle macro C++)? Probabilmente qualcosa di nuovo in .NET 4.0 è correlato a questo argomento?

Grazie.

P.S. Ogni pensiero è benvenuto.

Answer 1

Se la gestione delle eccezioni è esattamente lo stesso in tutti i metodi, si potrebbe fare qualcosa di simile:

void CallService(Action method) 
{ 
    try 
    { 
     // Execute method 
     method(); 
    } 
    catch(MyException2 exc) 
    { 
     ... process exception of MyException2 type 
    } 
    catch(MyExc1 exc) 
    { 
     ... process exception of MyExc1 type 
    } 
    catch(Exception exc) 
    { 
     ... process exception of Exception type 
    } 
} 

Poi, si può solo riscrivere il codice del client di fare:

int i = 3; 
string arg = "Foo"; 
this.CallService(() => this.Method1(i)); 
this.CallService(() => this.Method2(arg, 5)); 

Questo permette ai metodi Method1 e method2 di essere semplicemente:

void Method1(int arg) 
{ 
    // Leave out exception handling here... 
    ... required functionality 
    ... process and return result if necessary 
} 

void Method2(string stringArg, int intArg) 
{ 
    // Leave out exception handling here... 
    ... required functionality 
    ... process and return result if necessary 
} 

Answer 2

so che è cattiva pratica, ma se avete la stessa identica gestione degli errori in ogni dichiarazione di cattura, quando perché non utilizzare l'ultima istruzione catch come una cattura tutti?

Questo, naturalmente, assume tutte le eccezioni ereditano da Exception.

Answer 3

Perché non limitarsi a inserire il codice in un metodo di supporto per farlo per te (puoi aggiungere le nuove eccezioni di cui hai bisogno in futuro allo HandleException, cosa che lo rende abbastanza scalabile)?

try 
{ 
    ... required functionality 
} 
catch (Exception e) 
{ 
    HandleException(e); 
    throw; // only if you need the exception to propagate to caller 
} 


private void HandleException(Exception e) 
{ 
    if (e is MyException2) 
    { 
     ... process exception of MyException2 type 
    } 
    else if (e is MyExc1) 
    { 
     ... process exception of MyExc1 type 
    } 
    else 
    { 
     ... process exception of Exception type 
    } 
} 

Answer 4

Guarderei da vicino cosa stai facendo per "elaborare" queste eccezioni. Ci sono buone probabilità che non ti servano affatto blocchi di cattura e che dovresti consentire le propagazioni delle eccezioni.

Answer 5

In un lampo improvviso di geekiness (e per mostrare ciò che si poteva, ma molto probabilmente non dovrebbe e non si vuole fare): è possibile rendere il tutto più compositivo e riusabile generando funzioni al volo che contengono l'eccezione logica di movimentazione:

static class ExceptionHandlerExtensionMethods 
{ 
    // extend to Func<T> as desired 
    public static Action Catching<T>(this Action what, Action<T> handler) 
     where T : Exception 
    { 
     return() => 
     { 
      try 
      { 
       what(); 
      } 
      catch (T ex) 
      { 
       handler(ex); 
      } 
     }; 
    } 
} 

Ora è possibile implementare e funzioni di gestione specifiche riutilizzo eccezione di tipo da qualche parte, e li compongono nella gestione delle eccezioni di qualche altro metodo.

Per rimuovere la ridondanza, è possibile scrivere una funzione di supporto che aggiunge le funzioni "tipiche" al gestore delle eccezioni a che cosa mai si desidera chiamare e chiamare questo metodo decorato invece.

Answer 6

Utilizzando il metodo Callservice da Reed Copsey:

void DoSomething(object param1, int param2) 
{ 
    this.CallService(() => 
    { 
     // work with param1 and param2 here 
    } 
} 

Per i casi in cui è necessario restituire un valore, potrebbe essere necessario duplicare Callservice per restituire un parametro di tipo.

T CallService<T>(Func<T> callback) { /* ... */ } 

Answer 7

Ho fatto quanto segue in una situazione simile. Vi mostrerò la tecnica a due passi ...

---

Fase 1. Creare un metodo che fornisce un contesto di esecuzione specifica per altro codice:

// this static method is responsible for setting up a context for other code 
// to run in; specifically, it provides the exception handling "plumbing": 
public static void guarded(Action action) 
{      // ^^^^^^^^^^^^^ 
    try    // actual code to be executed 
    { 
     action(); 
    } 
    catch (SomeExceptionA ea) 
    { 
     // handle exception... 
    } 
    catch (SomeExceptionB eb) 
    { 
     // handle exception... 
    } 
    // etc. 
} 

---

Fase 2 Applicare questo contesto a qualsiasi parte di codice:

Successivamente, è sufficiente "avvolgere" questa gestione delle eccezioni attorno all'atto codice sessuali nelle metodi:

public void MethodA() 
{ 
    guarded(() => // <-- wrap the execution handlers around the following code: 
    { 
     // do something which might throw an exception... 
    }); 
} 

public void MethodB() 
{ 
    guarded(() => 
    { 
     // do something which might throw an exception... 
    }); 
} 

---

Sommario:

L'idea generale è quello di scrivere una funzione (guarded nell'esempio precedente), che stabilisce un contesto di esecuzione specifica per altro codice da eseguire. (Il contesto in questo esempio fornisce la gestione delle eccezioni.) Il codice che deve essere eseguito in questo contesto è fornito come funzione lambda. Si potrebbe anche adattare la funzione di creazione del contesto in modo che il codice nella funzione lambda possa restituire un valore.