2010-04-27 14 views
6

Ich habe ein System, wo die employeeId immer existieren muss, es sei denn, es gibt ein zugrunde liegendes Problem.C# Throw Ausnahme bei Verwendung Assert?

So wie ich es sehe, ist, dass ich zwei Möglichkeiten diesen Code zu überprüfen:

1:

public void GetEmployee(Employee employee) 
{ 
    bool exists = EmployeeRepository.VerifyIdExists(Employee.Id); 
    if (!exists) 
    { 
    throw new Exception("Id does not exist"); 
    } 
}  

oder 2:

public void GetEmployee(Employee employee) 
{ 
    EmployeeRepository.AssertIfNotFound(Employee.Id); 
} 

Ist Option # 2 akzeptabel die C# Sprache?

Ich mag es, weil es in das ordentlich ist Ich mag nicht zu „throw new Exception suchen (“ bla bla bla ") geben Meldungen outsite den Klassenbereich.

+1

Warum lässt Ihre VerifyIdExists-Methode nicht die Ausnahme in Ihrem Namen auslösen? – Tejs

+0

Ich glaube nicht, dass etwas falsch ist mit dem, was Sie außer IMHO haben Ich würde den Namen in ThrowIfNotFound ändern. Ich nehme an, das ist etwas, das Sie sowohl in den Release-Build als auch in Ihren Debug-Build einbeziehen möchten. –

Antwort

3

Es hängt davon ab, was Sie von Assert bedeuten.

Sie könnten Debug.Assert (oder Trace.Assert verwenden, wenn Sie möchten, dass es auch im Freigabemodus funktioniert.) Dies ist jedoch nicht so nützlich, da es das Programm anhält und ein Dialogfeld öffnet, bis ein Benutzer etwas drückt Das ist gut für ein nicht überwachtes System, daher würde ich empfehlen, stattdessen in den meisten Fällen zu werfen, da Sie entscheiden können, wie Sie auf den Fehler reagieren möchten - stoppen Sie das Programm oder loggen Sie sich einfach ein und versuchen Sie, fortzufahren.

Aber wenn wir davon ausgehen, dass Ihre Assert Methode prüft ihr Argument und möglicherweise eine Ausnahme auslöst, dann ja, ich denke, das ist ein guter Weg, es zu tun.

Um ein Beispiel auszuwählen, werden in Jon Skeets morelinq beide Methoden verwendet. Zum Beispiel here:

public static IEnumerable<TSource> AssertCount<TSource>(
    this IEnumerable<TSource> source, 
    int count, 
    Func<int, int, Exception> errorSelector) 
{ 
    source.ThrowIfNull("source"); 
    if (count < 0) throw new ArgumentException(null, "count"); 
    errorSelector.ThrowIfNull("errorSelector"); 

    return AssertCountImpl(source, count, errorSelector); 
} 
+1

Ja. Meine Assert ist für "Eine Ausnahme werfen". Danke j. – guazz

+0

@guazz: Das erste Mal, als ich deine Frage gelesen habe, dachte ich, du würdest Werfen mit Behauptung vergleichen - und aus dem Blick auf die anderen Antworten und Stimmen, so auch alle anderen. Vielleicht möchten Sie Ihre Frage neu formulieren, um sie klarer zu machen. –

+0

Erweiterungsmethode für Argument Ausnahme? –

1

Verwenden Ausnahmen, das, was sie sind dort - außergewöhnliche Umstände. Alle Standard-.NET-Bibliotheken verwenden diese Methode zum Behandeln solcher Umstände, sodass Sie Ihre Hinweise von Microsoft erhalten.

5

In der Regel sollten Sie Ausnahmen nur unter Exceptional Umstände werfen. Seit diesem einen solchen Umstand ist das Werfen einer Ausnahme das Richtige.

0

Die Idee hinter Behauptungen, wie ich sie immer verwendet habe, ist, dass sie sofortige Rückmeldung sind, wenn ein Debug-Build ausgeführt wird. Irgendwie in deinem Gesicht, dass etwas passiert ist. Oder in Datei eingeloggt, wenn die App so eingerichtet ist.

Ausnahmen werden verwendet, um außergewöhnliches Verhalten zu behandeln, wie oben erwähnt.

Was ich tue, besonders früh in Projekte Lebenszyklus könnte wie etwas sein:

public void GetEmployee(Employee employee) 
{ 
    bool exists = EmployeeRepository.VerifyIdExists(Employee.Id); 
    Debug.Assert(exists, "employee does not exist for id: " + Employee.Id); 
    if (!exists) 
    { 
    throw new Exception("Id does not exist); 
    } 
} 

Vielleicht die Debug.Assert refractoring, sobald der erste Schluckauf behandelt werden.

Verwandte Themen