Memorizzare le informazioni sulle eccezioni come variabile membro per una query successiva, cattiva pratica? [duplicare]

2

Considerando il modo migliore per gestire le eccezioni, la risposta a questa domanda potrebbe essere quella di gestire l'eccezione in una posizione diversa o di non gestirla affatto ma di controllare il flusso del codice. Per favore fatemi sapere se questo è il caso.

Diciamo che abbiamo una classe NetworkConnection . Questa classe ha un metodo Connect che assomiglia a:

bool Connect(string ipAddress, int port)
{
   try
   {
       // do connection, when successful
       return true;
   }
   catch (HostNotFoundException ex)
   {
       return false;
   }
   catch (...)
   {
       ...
   }
}

Se un altro oggetto che usa questo metodo vuole sapere quale eccezione si è verificata, non può scoprirlo. Ci sono tre modi per affrontare questo che posso pensare:

  1. Restituisce un codice di errore
  2. Salva una variabile sull'oggetto NetworkConnection che contiene alcune informazioni di errore, forse una stringa che dice "Host non trovato", che può essere interrogata da un altro oggetto in seguito.
  3. Cattura l'eccezione più in alto nella base del codice.

Voglio scegliere il secondo metodo, ma sento che sarebbe una cattiva idea. Qual è la decisione migliore qui, perché (potenzialmente) è il mio prescelto cattivo?

    
posta innova 01.07.2015 - 14:56
fonte

1 risposta

0

È una pratica abbastanza comune - programmi C (e altri sistemi, ad esempio errno ) spesso per memorizzare l'ultimo errore in una posizione in modo da poter selezionare i dettagli se una funzione ha restituito un codice di errore. Non c'è motivo per cui tu non possa fare lo stesso.

Tuttavia, se lo fai devi prendere in considerazione alcune cose. I thread sono molto importanti, ogni informazione di errore deve essere memorizzata per thread e non si può ottenere altro che l'ultimo errore, che potrebbe essere complicato se ci si aspetta una diversa area di codice per leggerlo - una chiamata diversa potrebbe cambiarla tra il tempo in cui lo scrivi e vuoi leggerlo. Di conseguenza, non è raccomandato in generale.

Quello che potresti voler fare è registrare tutti gli errori e lasciare che l'altra routine legga fuori dalla lista, questo può funzionare per il controllo o errori che sono specificamente progettati per l'utente da visualizzare.

Le eccezioni IMHO sono per circostanze eccezionali. Per gli errori attesi , un codice di ritorno è superiore. L'utilizzo di eccezioni per il code-flow è una cattiva pratica. Restituisce un codice di errore e consente al chiamante di decidere cosa fare con quello. SE è necessario utilizzare le eccezioni, gestirlo ulteriormente nello stack delle chiamate.

    
risposta data 01.07.2015 - 15:10
fonte