2008-10-24 16 views
6

Ich habe einen Code, der eine bestimmte Ausnahme ignoriert.Ausnahmen ignorieren

Dies führt natürlich zu einer Kompilierzeitwarnung, da ex nicht verwendet wird. Gibt es einen Standardannoop, der verwendet werden sollte, um diese Warnung zu entfernen?

Antwort

12

neu schreiben Sie es einfach als

catch (UnauthorizedAccessException) {} 
+0

Ich hatte keine Ahnung, das war erlaubt, schick, danke. – stimms

+0

Aber bitte noch den Kommentar!Nur ein vollständig leerer Block im Produktionscode sollte Code Review IMO nicht passieren. –

+0

> "Aber bitte fügen Sie noch den Kommentar ,,,". Dem nicht zustimmen. "catch (SomeException) {}" sagt bereits eindeutig "Ignore SomeException" und in vielen Fällen wird ein zusätzlicher Kommentar überflüssig. – Joe

1

ich normalerweise

Debug.WriteLine(ex.message) 

(so ich in der Ausnahme einen Haltepunkt nur einstellen, wenn nötig, auch)

2

Als Dave M . und tvanfosson sagten, Sie möchten es als

catch (UnauthorizedAccessException) {} 
umschreiben

Die größere Frage, die gefragt werden sollte, ist jedoch, warum Sie eine Ausnahme beim Ignorieren (häufig als Schlucken der Ausnahme) fangen. Dies ist im Allgemeinen eine schlechte Idee, da es Probleme in der Anwendung zur Laufzeit verstecken kann (und normalerweise tut), die zu sehr seltsamen Ergebnissen führen können und eine schwierige Zeit, sie zu debuggen.

+0

Zumindest ist es besser als "catch (Exception) {}". – MusiGenesis

+0

Wahr, aber nur geringfügig besser. –

+0

Ich denke, es ist manchmal in Ordnung, eine Ausnahme zu fangen und es zu schlucken, aber es sollte immer ein Kommentar sein, der erklärt, warum du es tust. –

-1

Obwohl ich ein Java-Entwickler (nicht C#) bin, hat @ Scott Dorman absolut Recht. Warum "schluckst du die Ausnahme"? Besser noch, was könnte die UnauthorizedAccessException werfen? Hier sind gesunder Menschenverstand Möglichkeiten:

  1. Die Datei nicht existiert
  2. Das Verzeichnis nicht
  3. den aktuellen Thread der Kontrolle existiert nicht die richtigen Sicherheitsberechtigungen verfügen. In der * nix-Welt befindet sich der aktuelle Thread möglicherweise in der falschen Gruppe oder im falschen Benutzer.
  4. Die Festplatte ist abgestürzt
  5. Die ACL der Datei wird nur zum Schreiben festgelegt, aber nicht gelesen. Ebenso für das Verzeichnis.

Das obige ist natürlich eine unvollständige Liste.

+0

Drei dieser Common-Sense-Möglichkeiten werden keine UnauthorizedAccessException auslösen. Und genau das ist der Grund, warum die Methode die Ausnahme verschluckt: Sie will nur die Dateien, auf die sie zugreifen darf. –

1

den Kommentar in Ihrer ursprünglichen Code ist, glaube ich zu tun eine genaue Beschreibung dessen, was Sie versuchen Angenommen, Sie es wie folgt schreiben wollen:

foreach (FileInfo fi in di.GetFiles()) 
{ 
    //TODO: what exceptions should be handled here? 
    collection.Add(fi.Name); 
} 

// populate collection for each directory we have authorized access to 
foreach (DirectoryInfo d in di.GetDirectories()) 
{ 
    try 
    { 
     populateItems(collection, d); 
    } 
    catch (UnauthorizedAccessException) 
    { 
     //ignore and move onto next directory 
    } 
} 

Und dann müssen Sie auf dieser TODO arbeiten Artikel.

+0

Das TODO-Element ist einfach - fast sicher möchten Sie dort keine Ausnahmen behandeln. – Joe

+0

Sie haben wahrscheinlich recht. Aber ich werde mir nicht vorstellen, zu wissen, was das ursprüngliche Poster für den Code vorsieht, und in einem Code-Review würde ich ihn dazu bringen, es mir zu sagen. –

1

Ich stimme den Leuten zu, die sagen, dass es wahrscheinlich eine schlechte Idee ist, die Ausnahme einfach zu ignorieren. Wenn Sie es nicht erneut werfen, dann loggen Sie es irgendwo irgendwo ein. Ich habe kleine Tools geschrieben, die eine Liste von Dateien verarbeiten, bei denen ich keine Fehler in einzelnen Dateien haben wollte, um das gesamte Programm zum Absturz zu bringen. In solchen Fällen würde ich eine Warnmeldung ausgeben, damit ich sehen konnte, welche Dateien übersprungen wurden. Das einzige Mal, dass ich jemals eine Ausnahme erhalte, ohne sie zu benennen, wie in catch (xxxException), ist, ob ich auf irgendeine Weise darauf reagieren und sie dann erneut werfen werde, damit ich sie einfangen kann eine äußere Routine. Zum Beispiel:

try 
{ 
    // do something 
    // ... 
} 
catch(UnauthorizedAccessException) 
{ 
    // react to this exception in some way 
    // ... 

    // let _someone_ know the exception happened 
    throw; 
}