Null Verständnis

   1:  public interface IUserRepository

   2:  {

   3:      User GetUserByID(Guid userID);

   4:  }

Hi Thomas,

also nur NULL als Rückgabe bei der Abfrage nach Usern in einem Repository wäre mir persönlich zu wenig. Was hältst Du denn von einer weiteren Methode in Deinem Repository, bei der Du abfragen kannst, ob der benötigte User existiert und wenn ja in welchem Zustand. Ich denke gerade bei einer Benutzerverwaltung kann das sehr sinnvoll sein. Hier mal mein Gedankenanstoß in Code (ich hoffe das, das hier im Kommentar funktioniert):

public interface IUserRepository
{
bool ContainsUser(Guid userGuid, out SearchResult searchResult);

IUser GetUser(Guid userGuid);
}

public enum SearchResult
{
NotFound,
Deleted,
NotPublic,
NotAccessible
}

public interface IUser
{}

Ich denke das könnte die Auswahl der Antworten über das UI, für den Fall das kein User angezeigt werden kann, etwas vereinfachen. Oder?

Gruß
TOM

Danke für die Herausforderung, Thomas! Die nehme ich an. Was sollte also zurückgeliefert werden, wenn ein User mit der Id nicht existiert?

Ich bleibe dabei, dass Null zwar naheliegend ist, aber letztlich die falsche Lösung. Sie ist unr eben in unserem Entwicklerstammhirn ziemlich fest verdrahtet ;-)

Aber wir sind ja keine Reflexmaschinen. Wir können umlernen.

Also treten wir zurück und fragen erstmal: Wie steht es um die Kategorien? Was wird als Ergebnis erwartet? Bei der Mengenquery wurde ein Container erwartet und Null war keiner, also falsche Kategorie. Wie ist es aber hier? Es wird ein User, ein Objekt erwartet.

Wenn Null zurückkäme, dann würde das signalisieren: "kein Objekt". Hört sich gut an. Aber es wäre weiterhin ein sehr unspezifisches Nicht-Objekt.

Ich fände es daher in diesem Zusamenhang besser, einen NonExistentUser zurückzugeben. Der Vergleich wäre dann:

var user = repo.GetUserById(...);
if (user == User.NonExistent)
...

Ist das nicht auch sprechender als if (user == null)?

Dass so ein User fälschlicherweise irgendwo weiterverarbeitet würde, glaube ich nicht. All seine Eigenschaften/Methoden würden eine Exception werfen (throw new NullObjectAccessException<User>()). Das wäre sogar noch Aussagekräftiger als irgendwo eine Null Ref Exception zu sehen. Es wäre vielmehr sofort klar, was für eine Art Objekt da nicht existent ist.

Auch wenn ich diese Lösung schon für ausreichend halte, gibt es aber noch eine andere: GetUserById() wirft eine Exception.

Warum das? Weil der Zugriff auf eine Entität per Id etwas anderes ist als eine Query. Mengenabfragen liefern immer eine Menge zurück; die kann allerdings auch leer sein.

Fragen nach Identitäten können aber eigentlich keine "leere Identität" zurückliefern. (Was wäre das? Ein Template?) Woher sollte denn auch die Identität kommen (die GUID), nach der man sucht? Es muss eine zugehörige Entität geben. Alles andere ist ein Fehler!

Ergo: Wenn es keinen Datensatz zur GUID gibt, wird nicht Null und auch kein NonExistentUser zurückgegeben, sondern eine Exception geworfen. Ja, das halte ich sogar für die konsequentere, die bessere Lösung. Das entspricht der Semantik von Identität.

Puh, Herausforderung gemeistert ;-)

-Ralf

Ich habe ja Exceptions noch bei Ada in den Neunzigern gelernt, und da gab es wenig Diskussion: Rückgabewerte sind keine Fehlerbehandlung.

Natürlich gibt's 'ne UserNotFound-Exception. Warum haben wir den Exceptions, wenn wir nichtgefunde Dateien, falsche Indizes und alles andere auch durch null ausdrücken könnten? Ob die Exception oft oder weniger oft geworfen wird, steht dabei nicht zur Debatte.

> Puh, Herausforderung gemeistert ;-) @RalfW: glaub ich nicht ;-)

Vielleicht schaffe ich mit meinem Ansatz Anforderungen, die es nicht gibt. Dann würde ich natürlich sofort stoppen. Das kann aber nur Thomas beantworten ;-) Aber, warum sollte ich bei dem Versuch einen User zu ermitteln gleich eine Exception auslösen? Wenn ich in ein Kino gehe, Karten für eine Vorstellung kaufen möchte, dann bekomme ich doch von der Verkäuferin auch nicht direkt eine Backpfeife. Jede gute Kassiererin gibt mir Antworten, aus denen vielleicht Optionen entstehen.
"Eine Antwort könnte sein: Ich hätte noch eine reservierte Karte. Wenn Sie 10 Minuten warten, können Sie diese haben."
Es könnte aber auch die Antwort geben:
Diese Vorstellung ist für 20:00 Uhr nicht öffentlich. Kommen sie doch morgen wieder, dann können Sie eine Karte kaufen.
Oder man hat für das Ticket keine ausreichende Authentifizierung.

Also, warum eine Frage nach einem Objekt gleich mit einer Exception bestrafen. Für den Zugriff auf die Eigenschaft eines Objekt, dass es vielleicht noch gar nicht gibt, ja dann bin ich mit einer Exception dabei.

Fazit: Etwas Differenzierung bei der Wahl, Exception Ja/Nein, sollte es geben. Oder?

Gruß
TOM

Ich versuche beim Design der Repositories stets darauf zu achten, Methoden mehrfach verwendbar zu machen.

Beispiel:

Für die Authentifizierung werden E-Mail-Adresse und Passwort benötigt. Urprünglich gab es dafür eine Methode GetUserPasswordByEmail(), später kam aus anderem Grund noch GetUserByEmail() im Repository hinzu.

Also wurde aus:

var hashedPassword = UserRepository.GetUserPasswordByEmail(email);

if(hashedPassword != null)
// Passwort checken
else
// Login existiert nicht

Folgendes:

var user = UserRepository.GetUserByEmail(email);

if(user != null)
// Passwort checken
else
// Login existiert nicht

Aus diesem Grund versuche ich dann die Methoden so allgemeingültig und mehrfach verwendbar zu halten, wie es im Hinblick insbesondere auch auf Performance Sinn macht (ein Repository.GetAllusers().Single(u => u.Email == email) würde absolut tödlich enden). Auf ein ContainsUser() wie von Tom vorgeschlagen versuche ich also zu verzichten.

Grundsätzlich finde ich hier eine Exception angebracht, aber ich weiß nicht ob ich mir damit einen Gefallen tue, wenn ich diese dann x-fach behandeln muss (grundsätzlich versuche ich Exceptions gar nicht zu behandeln, sondern sie soweit wie möglich nach oben durchzureichen ...).

Glaube ich muss mal ne Nacht darüber schlafen ,-)

@TOM #8:
Ich denke, vielleicht ist es einfach übertrieben, eine Exception als Backpfeife zu betrachten.

Wenn Du sie einfach als Ausnahme vom Erwarteten betrachtest - was eben auch mal passieren kann - fällt es Dir vielleicht leichter, sie in Deinem Code zu akzeptieren...

@Thomas: Ich bleibe dabei, die GetUser sollte eine Exception werfen. Um das in #2 angesprochene Szenario umzusetzen, wrappe ich eben diese Methode mit einem UserNameExists, die eben diese Exception handeln kann.

Thommy

@Thomas(2) Fast. Ich würde das mit einem boolschen Returnvalue bauen, ich empfinde NULL immer als unpassend und unnötig (äquivalent zu Datenbanken) - es entspricht halt einfach nicht der Signatur der Methode.

Thommy

PS: Ein GraffitiCMS-Fan, sehr gut :)

@Thomas: Ich bleibe dabei, dass das Herausfischen über die Id (!) eine Exception werfen sollte.

Wenn du allerdings eine andere Abfrage machst, z.B. über die Email, dann musst du dir überlegen, was da die Semantik ist. Ist bei einer Email sichergestellt, dass es auch nur 1 User gibt, der die Email-Adr hat? Gibt es immer einen User für eine Email, nach der du fragst?

Ich würde sagen: 1. Du solltest eine Email nicht als Identitätsrepräsentant ansehen. Dafür gibt es eben die Id. 2. Deshalb solltest du nicht GetUserByEmail() definieren, sondern FindUsersByEmail() - und diese Funktion liefert wieder einen Container zurück. In dem sollte zwar normalerweise nur ein User sein, doch garantiert ist das halt nicht wie bei einer Id. Wir sind zurück am Ausgangspunkt.

(Falls du bei 1. widersprichst und die Email als Id ansehen willst wie eine Guid, dann gelten dafür natürlich dieselben Regeln wie für GetUserById(). Also sollte eine Exception geworfen werden, wenn es den User zur Email nicht gibt.)

-Ralf

Hmm,

Ich finde die Lösung von @Thomas Freudenberg gut. Konventionalisiert, klar, und angemessener Konsens zwischen Intuition, Lesbarkeit, Abhängigkeit und Performance. Ich habe das ab und an mal bei kleineren Projekten auch so gemacht, aber noch nie "im großen Stil" durchführen können - vielleicht weil solche weichen Konventionen auch so schwer über dutzende Entwickler vermittelbar sind.

Ansonsten würde ich Exceptions vorziehen, wenn es ein trivialer Kontext ist. Da kann ich die Argumentation von @Carsti gut nachvollziehen.

Aber es ist auch eine pragmatische Sache, NULL bei offensichtlichen Ausnahmen anzuwenden. Genauso, wie es notwendig ist, NULL im katastrophalen Kontext einzusetzen.

Ich bin kein großer Freund von NULL, habe es aber dennoch geschätzt, es manchmal effektiv einsetzen zu können. Deswegen finde ich es wichtig, eine gewisses "Null Toleranz"-Niveau zu entickeln.

Siehe Blog: http://www.gmbsg.com/null-toleranz/

Alles in Allem tendiere ich zu @Thomas Freudenberg's pragmatischer Lösung als "Best Match".

@Ilker #20 (ich bleibe mal hier damit die Diskussion nicht so zerrissen wird :-)), du schreibst:

Account SignIn(string user, string password);

"Es kann alles mögliche passiert sein – keine Verbindung zum Server, falscher Server, Verbindungsfehler, Connection Timouts, Benutzer nicht gefunden, Benutzer gesperrt, Passwort abgelaufen, falsches Passwort – all dies würde ich versuchen über Exceptions oder Return-Codes zu erledigen. Die meisten der Exceptions gibt es ja schon frei Haus vom Framework. Aber für das mich Unbekannte und Unerwartete gibt es immer noch eine Rückgabe, und die heisst NULL."

Warum in diesem Fall dann null? Etwas Unbekanntes kann ja höchstens für den Aufrufer passieren, aber innerhalb von SignIn() kannst du ja jeden Fall der Ausnahme mit einer Exception behandeln. Gerade hier wäre ein Boolean als Rückgabewert imho angebrachter. Oder?

@Thomas: Du wendest implizit die Regel an "Wenn im Zweifel, dann zumindest konsistent", wenn du sagst, Null sei bei Get...() ok. Darüber lässt sich natürlich reden, wenn wir bei "Null-Regeln" sonst nicht weiter kommen. Darauf kann sich auch jeder zurückziehen. Jeder kann seine Privatregeln aufstellen, die in seinem Anwendungsuniversum gelten. Das ist besser als nix. Keine Frage. Dein Muster ist verständlich. Damit könnte am Ende womöglich sogar ich leben ;-) Ich könnte die meinen Konsent geben. (Zum Begriff Konsent mehr hier: http://soziokratie.blogspot.com/2009/08/konsent.html)

Warum darf ein Repository aber nicht bewusst Fehler generieren? Das verstehe ich nicht. Scheint ein Entscheidungskriterium für dich zu sein, Null zurückzugeben. Wir eröffnen also eine zweite Diskussion ;-)

Mein Pflock im Boden: Ein Repo darf selbstverständlich einen Fehler werfen. Wenn eine Query syntaktisch/semantisch nicht korrekt ist, dann ist es die Aufgabe des Repo, das zu melden. Und es gehört für mich zur Semantik eines Repo, dass nach Entitäten nur mit gültiger Id gefragt wird. Ist die Id ungültig, d.h. die Entität nicht vorhanden, dann ist das ein Fehler.

Aber über diese Semantik lässt sich streiten, äh, diskutieren ;-)

Dann noch zu deiner Abneigung gegen den out-Param. Wo ist da das Problem? Ich kann mich dem kollektiven Widerwillen nicht anschließen. Nur weil Uncle Bob das doof findet, muss ich es nicht auch doof finden. Wir reden ja hier über ein Pattern: Try-Methode. Davon gibt es welche im Framework, an denen man kaum vorbei kommt. Also kennen es alle.

Im Sinne einer saubere Command-Query-Separation mag das nicht so schön sein. Aber nun... So schön CQS ist, solange mir keine Sagen kann, wie ich damit einen Stack intuitiv beschreibe, erlaube ich mir, davon auch mal abzuweichen. (Nach CQS dürfte es keine T Pop() Funktion geben.)

Ergo: Ich bin für das Try-Pattern, weil es elegant kurz ist. Und eine Exception ist der richtige Weg, um bei Nichtexistenz aus Get...() zu antworten.

-Ralf

Ach ja, man ersetze Find() durch TryGet() ... ganz durcheinander.

Hallo @all ;-)

Wow, so ein reger Austausch von Erfahrung und Ideen gefällt mir! Wenn diese Runden auch noch mehr in die UG-Treffen kommen, wäre ich ein echt glücklicher UG-Leader ;-) OK, ich schwuffte ab.

Nach dem ich nun eine Nacht über das Thema geschlafen habe, möchte ich ganz gerne meinen ersten Ansatz etwas nachbessern und auch etwas besser erklären. Ich glaube in meinem zweiten Kommentar hatte ich mich unvollständig ausgedrückt 8-(

@Carsten&@Alex: Mein Bild zu Exceptions als Backpfeife kommt aus der intensiven Entwicklungszeit mit dem Automatisierungs-Objektmodel von Visual Studio. Hier wurden in vielen Dictionaries und auch Repositories nur Get-Methoden angeboten. War das gesuchte Objekt nicht da oder entsprach nicht dem erwarteten Typ, wurde sofort Exception ausgelöst. Und das kostet viel Nerven und auch Performance. Code-technisch wird es am Ende die absolute try & catch Hölle. Der Wunsch nach einer Möglichkeit, eine Contains-Methode oder den as-Operator verwenden zu können ist in diesen Scenarios riesig und sollte meiner Meinung nach in keinem Repository vergessen werden.

Contains/Find/Get

@Aelx: OK, Enums != OCP ist gekauft ;-) Da steckte wohl der Lucky Luke in meiner Tastatur. Mein Lieblingsartikel zu OCP ist dieser hier: http://tinyurl.com/6gjw69

Für mich gibt es drei „must-have“ Anforderungen an ein Repository.

Contains: Die Methode sollte mir einfach den Hinweis geben ob das gesuchte überhaupt existiert. Da, wie bereits festgestellt, ein Enum als out-Parameter keine gute Wahl ist, sollte die Methode ein Boolean zurückgeben. Das ist für den Verwender die schnellste Variante herauszufinden, ob das Gesuchte überhaupt existiert.

Find: Die Methode Find gibt mir die Möglichkeit ein Flyweight des gesuchten Typen als Referenz zu erhalten. Das ist meiner Meinung nach immer dann sehr wichtig, wenn noch gar nicht fest steht wann und von wem das oder die gesuchten Objekte verwendet werden. Findet die Methode Find nichts, gibt sie NULL zurück.

Get: Für diese Methode finde ich es gut, wenn ich bei der Verwendung einen Typ in Verbindung mit der entsprechenden ID/oder des Keys angeben kann. Das würde die Wiederverwendung des Entwurfs erhöhen. Zusätzlich ist es meiner Meinung nach ein guter Ansatz, das Auslösen einer Exception über einen booleschen Parameter steuern zu können. True, es wird eine Exception ausgelöst und false, die Methode gibt einfach Null zurück. Wie schon angesprochen, Exceptions kosten viel Zeit und das kann den Entwurf für einige Szenarien unattraktiv machen.

Fazit: Aus meiner Erfahrung heraus ist es für ein Repository, das nicht nur in einem Szenario verwendet werden soll, sehr wichtig, eine gewisses Maß an Flexibilität mitzubringen. Nebenbei weiß ich, dass eine strenge Verwendung von Exceptions aus Gründen der Performance dazu führen kann, dass die angebotenen Patterns und APIs gern umgangen werden. Und wir wissen doch alle, dass Architekten, die die Einhaltung von Architekturvorgaben überwachen müssen, eine aussterbende Spezies sind. Viel besser ist es doch, wenn sich die Entwicklerteams in ihren Sprints mit entsprechenden Frameworks, APIs etc. selbst organisieren können und Herausforderungen, wie diesen Post von Thomas, durch konstruktive Diskussionen alleine lösen. :-) >Träume?<
TOM

Hier noch ein Beispiel,

was mein Problem mit TryGet() ganz gut visualisiert:

User user;
if (UserRepository.TryGetUserByEmail(clientID, email, out user) && SecurityService.CheckPassword(password, user.Password))
{
return true;
}

(Geschweifte Klammern für bessere Lesbarkeit hier eingefügt)

"User user" steht da scheinbar unbenutzt und gelangweilt in der Ecke rum, man muss schon genauer weiterlesen um zu sehen dass es als out-Parameter eine Zeile später verwendet wird. Das liest sich imho nicht sehr intuitiv und sieht auch nicht gut aus.

Aber mei, irgendwas is ja immer. Ich arrangiere mich damit ;-)

Ohne jetzt jede Antwort gelesen zu haben. Ich tendiere auch auf null wenn es den User nicht gibt.
Auser es interessiert mich wie so es ihn nicht gibt. Dann muss eine andere Lösung her.
Aber nicht mit Exceptions. Irgend wie sieht das nach Programmsteuerung mit Exceptions aus. Allerdings, wie kriege ich den User zurück und gleichzeitig eine Info über das "Wie so nicht gefunden". Ein out Parameter oder so?
Aber eher null und danach halt noch abklären wie so. Nicht mit Exceptions das Programm steuern. Schlussendlich ist es ja kein Fehler das der User nicht gefunden wurde.

Erstmal: Tolle Diskussion, hoffe sowas gibts des Öfteren :)

Nachdem ich mich durch die Kommentare hier gelesen habe setze ich mal meine persönliche Meinung ab:

1. Ich mag den out-Parameter nicht. Für mich gehört ein "Teil-Ergebnis" einer Methode in die Ergebnismenge und somit in den Rückgabe-Typ der Methode. Ich würde deshalb eher eine komplexe (generische) Klasse zurückliefern.
2. Wenn eine Methode eine Menge von Elementen zurückliefert, würde ich niemals erwarten, dass diese Menge "Null" ist. Eine Menge ist höchstens leer, aber immer existent.

Zum eigentlichen Thema:

Sind wir mal ehrlich - wie oft interessiert einen wirklich, warum ein bestimmtest Objekt was man angefordert hat nicht existiert?
In den meisten Fällen interessiert es mich nur, dass es nicht existiert, denn um den eigentlichen Grund für ein nicht Existieren zu finden bedarf es meist eh einer extra Recherche.

Nehmen wir mal ein GetUserByID(...):

Klar kann man da eine Exception werfen und sagen die ID existiert nicht. Und wie viele hier argumentieren: Woher kommt die ID? Da muss was faul sein wenn die ID nicht gefunden wird, also werf ich eine Exception!
Ich seh das nicht so. In Systemen die hoch performant arbeiten müssen gibt es Szenarien in denen IDs durch Löschung verloren gehen, während andere Prozesse, eventuell aus Performance Gründen, mit gecachten Daten arbeiten. In solchen Szenarien kommt es dazu, dass IDs angefragt werden die eventuell nicht mehr existieren. Wenn man für dieses Szenario jetzt mal darüber nachdenkt was einem das werfen einer Exception im GetXXX() bringt, komm ich zu dem Schluss, dass mir das verarbeiten der Exception nur mehr Arbeit bringt. Sie hat für den reinen Fall der Aussage: "Du ich hab da nix mit deiner ID" keinen Mehrwehrt gegenüber einem Null-Return. Im Gegenteil:

1. Muss der Entwickler, der die benutzte Methode nicht selber geschrieben hat, bescheid wissen, dass da 'ne Exception für kommt
2. Muss ich nen Try-Catch für schreiben der X Zeilen bringt und den Code unleserlich macht sowie das Nesting erhöht.
3. Unnötige Performanceeinbußen durch Exception-Handling


Meine ganz eigene Regel ist: Get-Methoden dürfen null zurückliefern. Sollte beim "Besorgen" des Objekts selber ein Fehler auftreten werden Exceptions geworfen. Wird hingegen das Objekt einfach nicht gefunden, wird "Null" zurückgeliefert. Eine Exception, dass das Objekt nicht existiert, bringt mir keinen Mehrwert.

Wie gesagt das ist meine Meinung. Für Diskussionen bin ich offen :)

@Jens: Wenn du für dich entscheidest, dass du auf out verzichten willst, finde ich das absolut okay.

Allerdings finde ich inzwischen persönlich eine Unterteilung in GetUserByID(id) [muss einen User liefern oder ne Exception schmeißen] und TryGetUserByID(id, out user) [gibt klar zurück ob der User existiert] besser weil sprechender und semantisch korrekter.

Ich muss ja beim Aufruf immer wissen ob der User definitiv in diesem Moment vorhanden sein muss, oder ob er auch bereits gelöscht sein kann und entsprechend verwende ich eine der beiden Methoden. Daraus könnte man eine Regel für alle Zugriffe erstellen, was den Code auch besser les- und wartbar macht.

Verzichtet man darauf wird beim Lesen immer erst dann klar, ob ein User in dem Moment auch nicht gefunden werden kann, wenn man eine Null-Prüfung anhängt.

Just my 2 cents.

Nee, nix catchen. Einfach krachen lassen und benachrichtigen. Ich finde die Informationen einer spezifischen Custom-Exception (UserWithIDNotFoundException) samt Message ("User with ID '{GUID}' not found") und anhängendem Stacktrace, der den Aufruf protokolliert, schon recht aussagekräftig.

Ich finde es interessant, wie sich "das Thema" jetzt entwickelt. Am Anfang war Null allein völlig ok - und jetzt ist eine rumpelnde spezifische Exception schon nicht mehr genug.

Mir scheint, dass es da lohnt, den Blick etwas zu weiten. Die allgemeinere Frage lautet: Was tun, wenn etwas nicht klappt?

Da kommt für mich das Thema Instrumentierung um die Ecke. Exceptions allein machen nicht glücklich ;-) Die können zwar einige Infos transportieren, doch im Zweifelsfall fehlt dann wahrscheinlich doch Kontext.

Wir können uns zwar über Null oder Exception als Meldung für einen Fehlschlag unterhalten. Und wir können uns über Standardexception vs custom Exception unterhalten. Das sind dann Gespräche über ein Mittel zur Meldung von Fehlschlägen.

Doch wenn es an die Interpretation der Umstände geht, dann kann ich heute Exceptions nicht mehr allein sehen. Die sind nur eine rote Lampe, die angeht. Die sagen nur "Jetzt ist etwas passiert!" Was aber passiert ist, das zu beschreiben, ist nicht ihre Aufgabe. Die Umstände soll (!) eine Exception nicht transportieren (auch wenn sie gern einen Stacktrace haben darf und einen aussagekräftigen Meldungstext).

Die Umstände sind vielmehr aus einem Log zu entnehmen. Das ist bei Problemen mit einem Flugzeug oder einem Schiff nicht anders. Da gibt es Black Box und Logbuch, die den Kontext automatisch bzw. manuell protokollieren. Wenn was schief geht (wie immer das angezeigt werden mag), dann schaut man in diese Aufzeichnungen, um die Umstände zu rekonstruieren.

@Jens: Eine Exception als Signal ist für mich also das richtige Mittel. Die Id von X, also den Kontext, in dem Y nicht gefunden wurde, den zu dokumentieren, das ist nicht die Aufgabe der Exception. Das ist Aufgabe eines Log.

Nicht nur sollten wir uns also Gedanken über den Umgang mit Misserfolgssituationen machen, sondern auch darüber, wie wir den allgemeinen Verlauf der Operationen unserer Software dokumentieren. Instrumentierung ist für mich da inzw. der Weg, über den ich nicht mal mehr nachdenken muss.

Derzeit favorisiere ich dafür Gibraltar (http://www.gibraltarsoftware.com/). In den Code streue ich Trace.TraceInformation() oder Trace.TraceError() oder Debug.Print() usw. ein. (Alternativ kann ich auch z.B. mit log4net protokollieren.) Und dann referenziere ich nur in der "Hauptassembly" Gibraltar mit ein paar App.Config Einstellungen.

Und anschließend kann ich entweder den Verlauf der Verarbeitung jeder Instanz (!) der Anwendung, die auf irgendeinem Rechner vor sich hinrumpelt, auf meinem Entwicklungsrechner verfolgen. Oder ich kann mir z.B. im Fehlerfall autom. ein Log zuschicken lassen.

Einfach mal ausprobieren. Das ist so unaufwändig, dass keiner es auslassen sollte. Und mit den TraceSource-Methoden des .NET Fx pinselt man sich auch nicht so schnell in eine Toolecke.

-Ralf

Was zur nächsten Frage führt - wie und wo man Logging in Form des konkreten Trace()-Aufrufs genau einsetzt. Wenn man nämlich beginnt einfach alle Methoden mit mehr als 3 Zeilen damit vollzupflanzen, hat man am Ende vielleicht schöne Logs, aber unleserlichen Code.

Ich denke da kommt's dann auf den Anwendungsfall an - im Fall einer normalen Webanwendung reicht mir häufig einfach das Ergebnis der Exception samt Stack trace im (Windows-) Log um im Anschluss vernünftig debuggen zu können. Da verzichte ich bisher tatsächlich auf eigenes Logging.

Da wo komplexere Dinge vonstatten gehen oder wo man nicht so leicht "ran kommt" (z.B. Windows-Dienste), wird natürlich ausgiebig geloggt :-).

Tolle Diskussion und super Thread!

Ich bleibe mal beim Ausgangsthema, der NULL Rückgabe. Exceptions, Logging und alles sind schöne Themen, trotzdem erstmal nur NULL :-)

@Thomas #22 - Wie willst Du bei der Signatur bool zurückliefern? Account SignIn(string username, string password). Da bleibt nur Exception oder NULL. Schreiben wir mal:

public Account SignIn(string username, string password)
{
Account account = null;

if (this.authority.Authenticate(username, password))
{
account = this.repository.GetAccountByUsername(username);
}

return account;
}

Das ist ein pragmatischer Ansatz. Natürlich sollte und kann man einen else-Branch mit einer AuthenticationException machen. Aber hier ist der Konsens eben NULL auf Failure. Schließlich könnte Authenticate und GetAccountByUsername auch Exceptions werfen. Das ist jetzt keine schöne Sache und ich würde es auch vermeiden wollen. Gesehen habe ich solchen Code aber schon zigfach.

Besser wäre da der TryXXX-Ansatz, wie schon in vielen Kommentaren erwähnt. Also sowas wie bool TrySignIn(string username, string password, out Account account) für mein Beispiel oder diese TryGetUser-Geschichte.

Das finde ich in vielen Fällen absolut ok und ausreichend. Die Syntax mit dem out ist zwar nicht das schönste, tut aber was es soll. Ich habe als Alternative auch ab und an mal Envelopes gesehen, was ich perönlich vor Allem bei service-orientiertem Code nicht schlecht finde:

interface IResult<T>
{
bool Success { get; }
T Value { get; }
}

IResult<Account> SignIn(string username, string password);

Das geht so ein wenig in die Nullable und Option-Ecke, wie es Ralf ja schon erwähnt hatte. Auch in Ordnung, vor Allem, wenn IResult<T> über struct als Valuetype durchgeht und dadurch abgesichert wird.

Zu dem TryXXX möchte ich noch etwas hinzufügen, was vor Allem für Webleute und die Hochlastfreunde unter uns wichtig ist. das TryXXX-Pattern hat den Nachteil CQRS nicht zu fördern. Das wirfd ganz besonders schwierig, wenn Du die R/W's auf auf die Repository-Infrastruktur runterbrechen musst, weil die Last dadurch besser gestemmt wird. Aber das ist ein Sonderfall und kann in 90% der Fälle "unbeachtet" bleiben.

My 2c,
Ilker

Hallo zusammen,
ich hätte da auch eine kleine Frage: wie macht ihr das bei Validierungen?
Angenommen ihr habt ihn eurer Business Logik Schicht eine Validierungsklasse die die Eingaben aus einem Formular validieren soll (Datumsprüfung usw.). Wirft eure Validierungsmethode eine Exception wenn die Validierung fehl schlägt oder arbeitet ihr da mit return codes?
PS: Es erfolgen mehrere Validierungen in dieser Methode (für jedes Property des übergebenen Formular-Objektes)

Ich denke, dass an dieser Stelle eine Exception nicht das Mittel der Wahl ist, da der User dann immer nur den ersten aufgetretenen Fehler visualisiert bekommt, was die Frustration beim nächsten Versuch und einem evtl. auftretenen Fehler vergrößert. Wir arbeiten in solchen Fällen immer mit einer List() von ValidationResult-Objekten, die u.a. einen Fehlercode, den lokalisierten Fehlertext und einen Schweregrad enthalten. Diese Auflistung ist dann sehr hübsch zu visualisieren.

Grüße
Thommy

Da hab' ich neulich meinen Weg zu beschrieben (genau wie hier gesagt):

http://blog.thomasbandt.de/39/2327/de/blog/validierung-gehoert-in-den-business-layer.html