Qualunque applicazione può andare in errore. Per quanto bene possa essere scritto il codice, ci sono fattori esterni che possono causare errori come la mancanza di connessione al database, un problema hardware ecc. Ciò che un'applicazione deve fare è gestire in maniera corretta queste eccezioni e affinché questo accada occorre che si verifichino tre condizioni fondamentali:

• l'utente deve essere notificato con un sistema che fornisce solo le informazioni minime dell'errore ed in maniera user-friendly. Ogni tecnologia ha le sue modalità di avviso; un'applicazione Windows Forms mostra generalmente una MessageBox o una form ad-hoc; un'applicazione web mostra una pagina apposita; poiché un servizio ha come utente una applicazione e non una persona fisica questo risponde con un messaggio particolare che fa capire al client che si è verificato un errore;
• l'errore deve essere loggato in maniera permanente (database, file, ecc) e gli amministratori del sistema devono essere avvisati del problema;
• l'applicazione non deve rimanere in uno stato di inconsistenza. Questo significa che l'operazione che ha scatenato l'eccezione deve essere transazionale altrimenti si rischia di lasciare le cose a metà strada con conseguenze imprevedibili.

WCF permette di gestire i primi due punti in maniera molto semplice, quasi banale, mentre il terzo punto è a discrezione dello sviluppatore.

Eccezioni: .NET vs SOA

WCF è interamente basato sul .NET Framework; questo significa che gestisce un errore sollevando un'eccezione la quale deve essere propagata al client. Tuttavia, WCF è completamente basato anche sugli standard WS-*, mentre le eccezioni sono qualcosa di tecnologicamente legato al mondo .NET. Un'eccezione in .NET non ha un'equivalente nel mondo Java e viceversa. Per rimediare a questa problematica e permettere comunque una corretta ed agnostica propagazione delle eccezioni, le specifiche WS-*hanno introdotto il concetto di SOAP Fault.

SOAP Fault

Come detto, quando si verifica un'eccezione, il server invia al client un SOAP Fault, il client interpreta il messaggio ed automaticamente solleva un'eccezione nel codice. Per default, l'eccezione che raggiunge il client viene trasformata in una CommunicationException. Questo comporta che il canale con il server viene chiuso ed il proxy non può più compiere chiamate e quindi può essere solo chiuso. Qualunque altra operazione genera un'eccezione direttamente sul client senza coinvolgere il server.

Un SOAP Fault in WCF viene rappresentato dalla classe FaultException e dalla sua derivata FaultException<T>. Mentre FaultException ha un uso generico, FaultException<T> è importantissima, poiché permette di portare con se i dettagli di un'eccezione che il server vuole propagare al client. T è, infatti, il tipo di un oggetto che si vuole trasferire al client. L'oggetto rappresentato dal tipo generico T può essere di qualunque tipo che sia serializzabile o un DataContract. Questo significa che T potrebbe essere qualunque ValueType o una classe demarcata correttamente.

E' importante notare che, poiché l'importante è che il tipo di T sia serializzabile, anche un'eccezione .NET può essere spedita in un Fault. Quest'ultima opzione è consigliabile per mantenere uno stile di programmazione il più simile a .NET.

public void GetCustomerById(int id){
  if (id < 1){
    throw new FaultException<ArgumentException>(new ArgumentException("L'id deve essere maggiore di zero"));
  }
  ...
}

Come si vede in questo snippet, per sollevare una FaultException basta istanziare la classe passando in input come primo parametro n oggetto del tipo T dichiarato. In realtà, il costruttore ha anche un secondo parametro molto utile per inviare ulteriori messaggi al client.

public void GetCustomerById(int id){
  if (id < 1){
    throw new FaultException<ArgumentException>(new ArgumentException("L'id deve essere maggiore di zero"), "Informazioni aggiuntive");
  }
  ...
}