Cosa fare con un'eccezione rilevata

Question

Quando il servizio WCF è disattivato, prenderò questa eccezione come questa.

public List<ProjektyEntity> GetProjekty() 
    { 
     try 
     { 
     return this.channel.GetProjekty(); 
     } 
     catch (EndpointNotFoundException exception) 
     { 
      //what to do at this point ? 
     } 
    } 

ma io non so cosa fare nella cattura block.I può restituire solo un oggetto di tipo List<ProjektyEntity> mi piacerebbe scrivere un messaggio all'utente, qualcosa come "Il servizio è disattivato "Il mio livello di presentazione è ASP.NET MVC. C'è qualche strategia per questo tipo di situazioni?

Answer 1

C'è una semplice regola: se non sai come gestire un'eccezione, non prenderla.

Rilevarlo e risintonizzare null o una lista vuota sarebbe la cosa peggiore che si possa fare perché sarà difficile eseguire il debug da dove proviene l'errore, o persino che si sia verificato un errore. Se lo fai avrai degli sviluppatori che tirano fuori i capelli.

Catturare un'eccezione e ridisegnarla come throw e; è anche negativa perché si perde lo stack originale. Rethrowing utilizzando throw; è OK a volte se si dispone di pulizia speciale è necessario fare solo se c'è un errore. Di solito questo non è il caso. Se si dispone di una pulizia da eseguire indipendentemente dal fatto che si sia verificato un errore, questo appartiene alla clausola finally.

Quindi, in generale, a meno che non ci sia qualcosa di sensato che è possibile fare per recuperare dall'errore, è sufficiente lasciare che l'eccezione si propaga al chiamante. Questo è il modo in cui le eccezioni sono progettate per funzionare.

Ci sono alcuni momenti in cui si potrebbe desiderare di prendere un'eccezione di aggiungere ulteriori informazioni (ad esempio per la registrazione), nel qual caso è necessario assicurarsi di utilizzare un InnerException per evitare di perdere le informazioni originali:

try 
{ 
    foo(bar); 
} 
catch (Exception e) 
{ 
    throw new FooException("Foo failed for " + bar.ToString(), e); 
} 

ma in generale è meglio non farlo a meno che non si abbia una buona ragione. Ciò impedisce agli utenti di rilevare un tipo specifico di eccezione: cattureranno l'eccezione e quindi dovranno attivare il tipo di InnerException. Non è divertente. Lascia che il chiamante veda l'eccezione originale.

Answer 2

Mi sembra che non si debba rilevare questa eccezione a quel livello; dovresti lasciare che l'eccezione si propaghi fino al livello del controller e lasciare che il livello del controller mostri il messaggio.

Answer 3

Posso vedere alcune opzioni qui. Determinare quale sia appropriato dipende probabilmente dall'applicazione.

• Mostra un errore e restituisce null. Pulito e semplice, ma inflessibile. Potrebbe non essere quello che vuoi in ogni caso in cui viene utilizzata questa funzione.
• Non prenderlo, lascia che il chiamante catturi questa eccezione. Può essere più facile per determinare la risposta appropriata alla funzione chiamante (es. Visualizzare un messaggio/riprovare in pochi secondi/ecc)
• prenderlo e lanciare una nuova ServiceNotAvailableException Un po 'più complessa di quanto l'opzione due, ma sarà rendere più chiaro il tuo codice.
• Basta restituire null. Probabilmente l'approccio meno auspicabile, a meno che questo servizio non funzioni, è comune e non è un grosso problema.

Answer 4

Creare un oggetto eccezione e abbastanza dettagliato debugging e gettarlo ai metodo

Answer 5

L'eccezione non dovrebbe essere catturati e manipolati in questo contesto è stata chiamata. Deve essere gestito a un livello molto più alto avendo accesso a qualsiasi console in generale.

Il meglio che si può fare qui è registrare l'eccezione con i dettagli necessari e ripetere correttamente.

Answer 6

Ci sono diversi approcci:

1) Non intercettare l'eccezione, e lasciare che il chiamante (livello di interfaccia utente) gestirlo

2) intercettare l'eccezione in modo da poter fare tutto il necessario a che fare, e poi ri-gettarlo

catch (EndpointNotFoundException exception) 
{ 
    CleanUpMyOwnState(); 
    throw;     // Pass the exception on the to the caller to handle 
} 

3) Convertire l'eccezione in un altro tipo (per renderlo più facile da gestire nel chiamante):

catch (EndpointNotFoundException exception) 
{ 
    CleanUpMyOwnState(); 
    throw new InvalidOperationException("Endpoint was not found", exception); 
} 

4) catturarlo, e quindi restituire un codice di errore (ad esempio null), in modo che il chiamante non ha bisogno di utilizzare la gestione delle eccezioni a che fare con esso (ma non c'è alcun vantaggio reale per fare questo)

5) Cattura l'eccezione e segnala l'errore all'utente stesso. Questa è probabilmente una cattiva idea: dovresti tenere tutti i rapporti sugli errori nel tuo livello di interfaccia utente.

Answer 7

public List<ProjektyEntity> GetProjekty() 
    { 
     try 
     { 
     return this.channel.GetProjekty(); 
     } 
     catch (EndpointNotFoundException exception) 
     { 
      'Write here Some Clean Up Codes 
      ' Log it somewhere on your server so that you can fix the error 

     } 
    }