Ansatz 1:
%Vor%Ansatz 2:
%Vor% Warum würde ich die Parameter in Ansatz 1 validieren und nicht nur auf MailMessage warten, um eine Ausnahme auszulösen (Ansatz 2) und mir sagen, dass ich einen leeren Wert from oder to an den Konstruktor übergeben habe ?
Also warum sollte ich meine eigene Ausnahme werfen?
Der Grund dafür ist ziemlich einfach - es erleichtert das Debuggen.
Für jede gegebene Methode (und dies trifft auf komplexere Methoden zu), die einen Nicht-Null-Parameter erfordert, wird es für jemanden, der ein Ausnahmeszenario debuggt, viel einfacher sein, eine explizite Ausnahme von SendMail zu sehen, "hey , 'from' ist null; ich brauche es nicht ', als wenn ein Methodenaufruf innerhalb von SendMail (oder sogar ein verschachtelter Methodenaufruf darin) eine NullReferenceException auslöst (was letztlich passiert, wenn Keine der fraglichen Methoden führt Nullprüfungen durch.)
Dann haben Sie das Szenario, in dem - 6 Monate später - Sie entscheiden, dass SendMail etwas anderes tun muss; z.B. (als ein triviales Beispiel) setze eine Art von Audit-Flag in einer Datenbank. Wenn Sie nun die Methode einfach umfallen lassen, haben Sie ein ungültiges Flag (oder Sie tun dies, abhängig von der Reihenfolge der Dinge in Ihrer Methode). Viel besser zu sagen "eigentlich, wenn meine Parameter ungültig sind, scheitern einfach sofort", anstatt die Methode weitermachen zu lassen und mögliche Nebenwirkungen zu haben.
Im Allgemeinen denke ich, dass das Auslösen einer eigenen Ausnahme gerechtfertigt ist, wenn Sie relevantere Informationen als die von Ihnen aufgerufene Funktion eingeben können (entweder um eine spezifischere Ausnahme in Ihrem Code zu behandeln oder um eine bessere Fehlermeldung an die Benutzer).
In diesem Fall scheint es, dass Sie keine Informationen hinzufügen würden, die Send() nicht könnte.
smtp.SendMail wird eine InvalidOperationException (im System-Namespace) auslösen
In diesem Fall werfen Sie einen geeigneteren Ausnahmetyp, vom Typ Typ ist es leichter zu verstehen und fängt die Ausnahme ab. InvalidOperationException ist eine sehr allgemeine Klasse. Durch das Auslösen einer eigenen Ausnahme ist der Code lesbarer und die gleiche Ausnahme kann auch dann gehandhabt werden, wenn Sie die Methode zu einem späteren Zeitpunkt ändern, z. B. indem Sie einen anderen Mailclient verwenden.
ehm ... bist du in 100% sicher, dass var msg = new MailMessage(from, to, subject, body) { IsBodyHtml = true };
wird diese Ausnahmen werfen? Ansatz 2 ist undefiniertes Verhalten . Wie sollte das Gerät getestet werden?
Was macht SendMail ("", "", "")? extacly? es ist nicht klar aus dem zweiten Ansatz.
Sie könnten einen Kommentar hinzufügen. aber warum? Das ist nicht clean code
arroach 1 definiert eindeutig, wo die Funktion fehlschlägt. und wie es mit Fehlern umgehen wird. Dein Code sollte klarstellen, was ist, nicht Kommentare.
P.S.
wirf neue ArgumentNullOrWhiteSpaceException("from") ; wird in Ihre SendMail-Funktion geworfen, die der Quelle des Problems am nächsten ist.
Wenn Sie Approach 2 nur Gott weiß, wie tief in Ihrem Anruf Vermietung wird es gefangen werden, wenn überhaupt.
könntest du das auch verbessern, indem du etwas wie:
schreibst ArgumentNullOrWhiteSpaceException("from - this is usually caused if poo is not bared by poo in goo") ; "Das könnte dein Leben ein paar Monate später vereinfachen.
Tags und Links c#