Częste błędy w programowaniu in.Net podczas obsługi wyjątków? [zamknięte]

Ponowne rzucanie WYJĄTKÓW w ten sposób:

try 
{ 
   // some code here
}
catch(Exception ex)
{
   // logging, etc
   throw ex;
}

To zabija ślad stosu, Tworzenie jest znacznie mniej użyteczne. Prawidłowa droga do rethrow będzie taka:

try 
{ 
   // some code here
}
catch(Exception ex)
{
   // logging, etc
   throw;
}

Wyłapywanie wszystkich wyjątków, gdy w wielu przypadkach powinieneś spróbować wyłapać konkretne wyjątki:

try {
  // Do something.
} catch (Exception exc) {
  // Do something.
}

Zamiast:

try {
  // Do something.
} catch (IOException exc) {
  // Do something.
}

Wyjątki powinny być uporządkowane od najbardziej konkretnego do najmniej.

Przemyślenie wyjątku z bezsensowną wiadomością.

try
{
    ...
}
catch (Exception ex)
{
   throw new Exception("An error ocurred when saving database changes").
}

Nikt nie mówi o takich pustych blokach....

 try{  
      //do something
    }
catch(SQLException sqex){  
        // do nothing  
    }

Również nigdy nie używaj obsługi wyjątków do tworzenia alternatywnych przepływów metod...

 try{  
     //do something  

 }catch(SQLException sqex){  

     //do something else  
 }

Nieużywanie using na IDisposable obiektach :

File myFile = File.Open("some file");
callSomeMethodWhichThrowsException(myFile);
myFile.Close();

MyFile nie zostanie zamknięte, dopóki nie zostanie wywołany finalizer myFile (co może nigdy nie być), ponieważ wyjątek został wyrzucony przed wywołaniem myFile.Close().

Właściwym sposobem na to jest

using(File myFile = File.Open("some file"))
{
    callSomeMethodWhichThrowsException(myFile);
}

To zostaje przetłumaczone przez kompilator na coś w rodzaju:

File myFile = File.Open("some file");
try
{
    callSomeMethodWhichThrowsException(myFile);
}
finally
{
    if(myFile != null)
        myFile.Dispose(); //Dispose() calls Close()
}

Więc plik zostaje zamknięty nawet w obliczu WYJĄTKÓW.

Zapomnij ustawić wewnętrzny wyjątek, gdy zmienisz przechwycony wyjątek

try
{
    ...
}
catch (IOException ioException)
{
    throw new AppSpecificException("It was not possible to save exportation file.")
    // instead of
    throw new AppSpecificException("It was not possible to save exportation file.", ioException);
}

Kiedy zamieszczałem tę odpowiedź, zapominam wspomnieć, że zawsze powinniśmy rozważyć, kiedy włączyć wewnętrzny wyjątek, czy nie ze względów bezpieczeństwa. Jak Eric Lippert zwrócił uwagę na inną odpowiedź na ten temat, niektóre wyjątki mogą dostarczyć poufnych informacji o szczegółach implementacji serwera. Tak więc, jeśli rozmówca, który będzie obsługiwał wyjątek, nie jest zaufany, nie jest dobrym pomysłem jest włączenie wewnętrznych informacji o wyjątkach.

Empty catch:

//What's the point?
catch()
{}

:

//Exceptions are for *adding* detail up the stack
catch (Exception ex)
{throw ex;}

Założenie wyjątku obejmującego wiele scenariuszy było czymś szczególnym. Prawdziwym scenariuszem była aplikacja internetowa, w której obsługa wyjątków zawsze zakładała, że wszystkie błędy są przerwami w sesji, a rejestrowane i zgłaszane wszystkie błędy jako przerwy w sesji.

Inny przykład:

try
{
     Insert(data);
}
catch (SqlException e)
{
   //oh this is a duplicate row, lets change to update
   Update(data);
}

To log Exception.Wiadomość zamiast wyjątku.ToString ()

Wiele razy widzę rejestrowanie kodu tylko komunikat wyjątku, podczas gdy powinien on rejestrować powrót metody ToString. ToString dostarcza znacznie więcej informacji o wyjątku niż wiadomość. Zawiera informacje takie jak wewnętrzny wyjątek i ślad stosu oprócz wiadomości.

Próba wyłapania OutOfMemoryExceptionlub StackOverflowException - prowadzą one do zamknięcia runtime ' u, a więc do wyłapania ich z tego samego procesu (a nawet z CLR jako całości?)

OutOfMemoryException: wyjątek, który jest wyrzucany, gdy nie ma wystarczającej ilości pamięci, aby kontynuować wykonywanie programu.

"począwszy od. NET Framework w wersji 2.0, obiekt StackOverflowException nie może zostać przechwycony przez blok try-catch i odpowiedni proces jest domyślnie zakończony. W związku z tym zaleca się użytkownikom pisanie kodu, aby wykryć i zapobiec przepełnieniu stosu."

Brak wyłapania możliwych WYJĄTKÓW wewnątrz funkcji obsługi. Może to spowodować, że niewłaściwy wyjątek będzie propagowany w górę.

Na przykład:

try
{
    DoImportantWork();
}
catch
{
    Cleanup();        
    throw;
}

Co się stanie, jeśli Cleanup() rzuci wyjątek? Nie chcesz widzieć wyjątku wskazującego na metodę Cleanup () w tym programie obsługi przechwytywania. Chcesz oryginalny błąd. Możesz spróbować zarejestrować błąd czyszczenia, ale nawet Twój kod logowania wymaga obsługi wyjątków, aby uniknąć wyrzucania z niego WYJĄTKÓW.

try
{
    DoImportantWork();
}
catch
{
    try
    {
        Cleanup();        
    }
    catch
    {
        // We did our best to clean up, and even that failed.
        // If you try to log this error, the logging may throw yet another Exception.
    }
    throw;
}

Wrong

try
{
   // Do something stupid
}
catch
{
   // ignore the resulting error because I'm lazy, and later spend
   // a week trying to figure out why my app is crashing all over
   // the place.
}

Lepiej

try
{
    /// do something silly.
}
catch (InvalidOperationException ex)
{
    /// respond, or log it.
}
catch (Exception e)
{
    /// log it.
}

Używanie wyjątków dla normalnej kontroli przepływu. Wyjątki powinny być wyjątkowe. Jeśli jest to operacja dobra / oczekiwana, użyj wartości zwracanych, itd.