Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Quando un servizio rileva un'eccezione o un errore imprevisto, esistono diversi modi per progettare una soluzione di gestione delle eccezioni. Anche se non esiste una singola soluzione di gestione degli errori "corretta" o "procedura consigliata", esistono più percorsi validi da considerare. È in genere consigliabile implementare una soluzione ibrida che combina più approcci dall'elenco seguente, a seconda della complessità dell'implementazione WCF, del tipo e della frequenza delle eccezioni, della natura gestita e non gestita delle eccezioni e di eventuali requisiti di traccia, registrazione o criteri associati.
Queste soluzioni sono descritte in modo più approfondito nella parte restante di questa sezione.
The Microsoft Enterprise Library
Il blocco di applicazioni di gestione delle eccezioni di Microsoft Enterprise Library consente di implementare modelli di progettazione comuni e creare una strategia coerente per l'elaborazione delle eccezioni che si verificano in tutti i livelli architetturali di un'applicazione aziendale. È progettato per supportare il codice tipico contenuto nelle istruzioni catch nei componenti dell'applicazione. Anziché ripetere questo codice (ad esempio codice che registra informazioni sulle eccezioni) in blocchi catch identici in un'applicazione, il blocco di applicazioni di gestione delle eccezioni consente agli sviluppatori di incapsulare questa logica come gestori di eccezioni riutilizzabili.
Questa libreria include un gestore di eccezioni per il contratto di errori pronto all'uso. Questo gestore delle eccezioni è progettato per l'uso ai confini del servizio WCF e genera un nuovo Fault Contract dall'eccezione.
I blocchi di applicazioni mirano a incorporare procedure consigliate di uso comune e fornire un approccio comune per la gestione delle eccezioni in tutta l'applicazione. D'altra parte, anche i gestori di errori personalizzati e i contratti di errore sviluppati da soli possono essere molto utili. Ad esempio, i gestori di errori personalizzati offrono un'ottima opportunità per promuovere automaticamente tutte le eccezioni a FaultExceptions e anche per aggiungere funzionalità di registrazione all'applicazione.
Per altre informazioni, vedere Microsoft Enterprise Library.
Gestione delle eccezioni previste
L'azione corretta consiste nell'intercettare le eccezioni previste in ogni operazione o in un punto di estendibilità pertinente, decidere se è possibile recuperarli e restituire l'errore personalizzato appropriato in un'eccezione FaultException<T>.
Gestione di eccezioni impreviste tramite IErrorHandler
Per gestire eccezioni impreviste, la procedura consigliata consiste nel collegare un IErrorHandler. I gestori degli errori intercettano solo le eccezioni a livello di runtime WCF (il livello "modello di servizio"), non a livello di canale. L'unico modo per associare un IErrorHandler a livello di canale consiste nel creare un canale personalizzato, che non è consigliato nella maggior parte degli scenari.
Un'"eccezione imprevista" non è in genere né un'eccezione irreversibile né un'eccezione di elaborazione; è invece un'eccezione utente imprevista. Un'eccezione irreversibile ,ad esempio un'eccezione di memoria insufficiente, una gestita automaticamente dal gestore eccezioni del modello di servizio , in genere non può essere gestita normalmente e l'unico motivo per gestire tale eccezione può essere eseguire una registrazione aggiuntiva o restituire un'eccezione standard al client. Un'eccezione di elaborazione si verifica nell'elaborazione del messaggio, ad esempio a livello di serializzazione, codificatore o formattatore, in genere non può essere gestita in un IErrorHandler, perché in genere è troppo presto o troppo tardi per il gestore errori intervenire nel momento in cui si verificano queste eccezioni. Analogamente, le eccezioni di trasporto non possono essere gestite da un IErrorHandler.
Con un IErrorHandler, è possibile controllare in modo esplicito il comportamento dell'applicazione quando viene generata un'eccezione. È possibile:
Decidere se inviare o meno un errore al client.
Sostituire un'eccezione con un'anomalia.
Sostituire un errore con un altro errore.
Eseguire la registrazione o il tracciamento.
Eseguire altre attività personalizzate.
È possibile installare un gestore degli errori personalizzato aggiungendolo alla proprietà ErrorHandlers dei dispatcher del canale per il tuo servizio. È possibile avere più di un gestore degli errori e questi vengono chiamati nell'ordine in cui vengono aggiunti a questa raccolta.
IErrorHandler.ProvideFault controlla il messaggio di errore inviato al client. Questo metodo viene chiamato indipendentemente dal tipo di eccezione generata da un'operazione nel servizio. Se non viene eseguita alcuna operazione, WCF presuppone il comportamento predefinito e continua come se non vi fossero gestori di errori personalizzati.
Un'area che potrebbe essere possibile usare questo approccio è quando si vuole creare una posizione centrale per convertire le eccezioni in errori prima che vengano inviate al client (assicurandosi che l'istanza non venga eliminata e che il canale non venga spostato nello stato Faulted).
Il metodo IErrorHandler.HandleError viene in genere utilizzato per implementare comportamenti correlati agli errori, ad esempio la registrazione degli errori, le notifiche di sistema, l'arresto dell'applicazione e così via. IError.HandleError può essere chiamato in più posizioni all'interno del servizio e, a seconda della posizione in cui viene generato l'errore, il metodo HandleError può o meno essere chiamato dallo stesso thread dell'operazione; nessuna garanzia è fatta in questo senso.
Gestione delle eccezioni esterne a WCF
Spesso, le eccezioni di configurazione, le eccezioni della stringa di connessione del database e altre eccezioni simili possono verificarsi all'interno del contesto di un'applicazione WCF, ma non sono eccezioni causate dal modello di servizio o dal servizio Web stesso. Queste eccezioni sono eccezioni "regolari" esterne al servizio Web e devono essere gestite esattamente come altre eccezioni esterne nell'ambiente devono essere gestite.
Tracciamento delle eccezioni
La traccia è l'unica posizione "catch-all" in cui è possibile visualizzare tutte le eccezioni. Per altre informazioni sulle eccezioni di traccia e registrazione, vedere Traccia e registrazione.
Errori del modello URI quando si usa WebGetAttribute e WebInvokeAttribute
Gli attributi WebGet e WebInvoke consentono di specificare un modello URI che esegue il mapping dei componenti dell'indirizzo della richiesta ai parametri dell'operazione. Ad esempio, il modello URI "weather/{state}/{city}" esegue il mapping dell'indirizzo della richiesta in token letterali, un parametro denominato state e un parametro denominato city. Questi parametri possono quindi essere associati in base al nome ad alcuni dei parametri formali dell'operazione.
I parametri del modello vengono visualizzati sotto forma di stringhe all'interno dell'URI, mentre i parametri formali di un contratto tipizzato potrebbero essere di tipi non stringa. Pertanto, una conversione deve essere eseguita prima che l'operazione possa essere richiamata. È disponibile una tabella dei formati di conversione .
Tuttavia, se la conversione non riesce, non è possibile comunicare all'operazione che si è verificato un errore. La conversione del tipo si manifesta invece sotto forma di un errore di trasmissione.
Un fallimento di invio nella conversione dei tipi può essere ispezionato allo stesso modo di molti altri tipi di fallimenti di invio installando un gestore degli errori. Il punto di estendibilità IErrorHandler viene chiamato per gestire le eccezioni a livello di servizio. Da qui, è possibile scegliere la risposta da inviare al chiamante, nonché eseguire attività e report personalizzati.