Würde die Liste returnen. Im Fehlerfall evtl Null oder instanziert ohne inhalt. Dann prüfen in welchem Zustand die Liste ist und entsprechend reagieren. Hab mir für solch einen Fall eine IsNullOrEmpty Extension geschrieben.

Es kommt drauf an.
Bei programminternen Problemen habe ich pro Form eine eigene Datei, in der ich Datenüberprüfungsfunktionen habe, in denen Datenpakete validiert werden. Werden Fehler in z.B. eingegebenen Daten gefunden, kommt ne MessageBox, die den Fehler zeigt und die Verarbeitung abbricht, sodass der User nachbessern kann:

Ich habe eine DLL, die mir Daten aus meiner Datenquelle holt. Da verwende ich keine MessageBox, sondern feuere ein Event und die eigentliche App reagiert darauf. Dann sag ich z.B. »keine Verbindung mit der Datenquelle vorhanden, das Programm wird beendet«. Eben weil viele meiner Programme ohne extern gespeicherte Daten nicht laufen. Und es ergäbe auch keinen Sinn, dass das Programm dann weiterläuft, da neu erzeugte Daten nicht in die Datenquelle zurückgeschrieben werden können, wenn schon von Anfang an klar ist, dass die Datenquelle nicht erreichbar ist.

ExceptionThrowing taucht bei mir nur dann auf, wenn ich nicht damit rechne, dass das Programm bis zu jener Codezeile überhaupt kommen kann:

Abfangen von Exceptions entsprechend dem Thread Fange nur Exceptions ab, die Du kennst und sinnvoll bearbeiten kannst.
Unerwartete Fehler fange ich mit einer programmweiten Routine ab, erfasse die greifbaren Daten und mache automatisch einen Screenshot. Außerdem informiere ich den User, dass was schiefgelaufen ist und ermögliche es ihm, die Daten zu speichern und das Programm zu beenden.

btw: Auch wenn es nur ein Beispiel von Dir war: das ByRef in Deiner Codezeile musst Du nur dann verwenden, wenn irgendwo in der Methode die Zeile lstDaten = auftaucht.

VaporiZed schrieb:

das ByRef

ich hau in dieselbe Kerbe: ByRef ist ein Spezial-Konstrukt für Fälle, wo eine Methode mehrere Werte verschiedenen Typs returnen muss.
Das ist wirklich sehr speziell, und hier schoma garnet der Fall. Am besten, du streichst erstmal ByRef aus deinem Wortschatz.
(Dassis schoma irritierend, weil vb6->vb.net - Konvertierer übergeben alle Vars byRef, weil das in vb6 halt Voreinstellung war.
Aber es ist ein gewisses Risiko der Code-Sicherheit, und in .Net braucht mans nicht, und dann soll mans auch lassen.)

Nochmal mein Einwurf: Sollte es wirklich so sein, dass in der Methode steht
dann muss der Parameter mit ByRef versehen werden. Ansonsten soll der ByRef-Zusatz weg. Eine von außen hereingereichte Klasseninstanz wird auch ohne ByRef in vollem Umfang innerhalb der Methode nutzbar sein.

Moin moin

​HoleDaten(byRef lstDaten as List Of(clsMeineDatenKlasse) As Boolean ( Old school eben )

Was ist daran falsch?
Wie man dann mit dem False weiter umgeht, das kann man doch individuell machen.

Ich habe mir für so etwas eine "LoggerClass" gemacht, welche die Fehler in ein "LogFile einträgt und dann ggf eine Nachricht im Label anzeigt oder auch mal eine MsgBox wirft.

Ebenso verwende ich dann manchmal das Try / Catch das dann auch in die "LoggerClass" führt.

Es kommt auf die verwendete Sprache und den Fehler an; ist also immer eine Einzelfallentscheidung.

Deine Variante ähnelt halt stark dem üblichen Vorgehen in C und (prä C++11) C++:



In modernen Hochsprachen gibt's jedoch viele unterschiedliche Arten und Weisen, mit Fehlern umzugehen.
Im Sinne von Clean-Code ist es übrigens nicht, eine Funktion nur ein bool zurückgeben zu lassen, wenn es mehrere Fehlerfälle gibt.
So gibst du nur zurück, dass etwas schiefgelaufen ist. Mit einem int kannste zumindest sagen, was genau schiefgelaufen ist.
Bei atomaren Operationen (oder solchen, die nur eine Aufgabe erledigen), kannst du sowas wie TryFoo() implementieren. Dann wäre ein bool auch okay.


Je nachdem, wie schwerwiegend der Fehler ist, kann man mit Exceptions arbeiten, oder wie hier ebenfalls gesagt wurde mit leeren Referenzen.
Da muss man aber aufpassen, dass man diese im Programm abfängt. Erwartet dein Programm immer, dass die Referenz zur Liste existiert, kannst du eine leere Liste statt null zurückgeben.

Andererseits wäre es in diesem Fall durchaus in Ordnung, sowas wie eine DataFetchException zu werfen, um deinem Programm zu signalisieren, dass eine Kernfunktion schiefgelaufen ist.
Zu Debugging-Zwecken kannst du, wie @Amelie das bereits gesagt hat, mit einem Logger arbeiten. Ich selber würde das zwar nicht selbst implementieren, sondern auf Serilog oder Nlog setzen, aber ist auch ein gangbarer Weg.
Dort kannst du dann in Debug-Builds auch den StackTrace mit ausgeben lassen und genau sehen, wo es geknallt hat. Wenn eine vorherige Exception der Grund für den Fehler ist, kannst du diese auch als InnerException weiter durchs
Programm propagieren.

Was man noch erwähnen sollte, ist dass in Dotnet immer alles außer ValueTypes per Referenz übergeben wird; d.h. deine Liste kann durch die Methode verändert werden und diese Änderung ist auch in dem Aufrufer sichtbar.

Anbei noch ein paar Beispiele.

Hallo,
eine Möglichkeit wäre die Verwendung eines Union Types. Um genauer zu sein den Option-Typ. Die Idee hinter dem Option-Typ ist, dass ein Wert repräsentiert werden kann, der möglicherweise oder möglicherweise nicht existiert. Aktuell bedarf es dazu noch ein Nuget-Paket (NuGet Gallery | LanguageExt.Core 4.4.9), aber es gibt einen Vorschlag für C#, dies in dotnet direkt zu implementieren.

Deinen Fall könntest du so abdecken (Beispielhaft)


Sollte in deiner Funktion aber eine Exception geworfen werden, kann man auch mit dem Result-Typ arbeiten. Bei Result kann man die Exception ebenfalls als Rückgabe ausgeben und im weiteren Programmablauf mit IfSucc() und IfFail() des Result-Typs arbeiten.


Prinzipiell kann man das auch mit Null-Typen erreichen, aber die Verwendung eines Option-Typ kann dazu beitragen, Code leichter zu verstehen.

Amelie schrieb:

Was ist daran falsch?
Wie man dann mit dem False weiter umgeht, das kann man doch individuell machen.

Ganz einfach: Was bedeutet denn True oder False bei einer Function, deren Name HoleDaten aber eine Anweisung ist? Allein der Anfang ist falsch. Die Methode kann ja HoleDaten heißen (obwohl die Benennung sehr allgemein gehalten ist; was für Daten, aus welcher Quelle, …). Aber das ist der Name für eine Sub, nicht für eine Function. Eine Function soll den Zustand von etwas wiedergeben, aber soll keine Daten ändern, eine Sub soll was machen, aber keine Zustände (z.B. per ByRef-Parameter) wiedergeben, siehe CQS. Aber eine Methode, die etwas macht und einen Wert wiedergibt (und dann noch einen mit hierfür ziemlich mieser Aussagekraft) ist schwerer zu durchschauen. Denn wie gefragt: Was bedeutet denn True oder False als Ergebnis für die Methode HoleDaten? Falsche Parameter übergeben? Keine Datenquelle verfügbar? Keine Daten verfügbar? Das Programm hat keine Lust, Daten zu holen (Stichwort KI)?

Folgender Aufbau wäre zielführender:

So kann man dem Programm (per Exception) oder dem User (per Fehleranzeige) detailliert klarmachen, ob der Vorgang funktioniert hat und wenn nicht, woran es lag. Aber ein einfaches True/False ist m.E. irgendwie … nix.

Der Aufbau hat einen von zwei Nachteilen:

• Entweder muss man 2 Abfragen pro Vorgang machen, also z.B. 1. gibt es Daten (Zeile#4) und 2. merke Dir die Daten (Z#8).
  
• Oder man ruft einen Zustand ab, merkt sich den Wert und macht damit die Validierung. Dann ist das Ganze immer abwechselnd Abfrage und Validierung. Find ich nicht so übersichtlich, daher teile ich solch eine Methode noch auf, damit Datenvalidierungen für die Übersicht immer nur am Anfang der Methode stehen.
  

Aber eben auch die genannten Vorteile, die m.E. überwiegen.

John422 schrieb:

Oder sehe ich das falsch?

Das siehst du falsch, weil Listen Referenzdatentypen sind. Auch ohne ByRef wird immer die Referenz übergeben und somit sind Änderungen auch im Aufrufer "verfügbar".

Ein Wort sagt mehr als tausend Bilder.

naja, guck deine Codes doch an.
Im ersten Fall ist in lstDaten ein anderes Objekt. Das Objekt, was vorher da war, existiert zwar noch, aber die Variable lstDaten enthält und ein anderes Objekt - nicht mehr das, wasses vorher war.

im zweiten Fall ist lstDaten nachwievor dasselbe, nur eben geleert.

Kannst du da keinen Unterschied erkennen?

John422 schrieb:

Aber wieso muß ich hier differenzieren?

Die New Anweisung sagt: Schreib xy in den Arbeitsspeicher. Dafür muss ein freier Platz verwendet werden. Wenn das Objekt geschrieben steht, kommt die Zuweisung, da wird n Zeiger für das neue Objekt gebaut.
Und das alte Objekt muss aufgeräumt werden.
Bei jeder Argumentübergabe an eine Methode dieses Spielchen automatisch mit machen, findest du? Ich denke da gibt es viel Widerspruch und deswegen gibt es das nicht.
Manche Argumente werden von Funktion zu Funktion gereicht. Manchmal nur durchgereicht.
Eine Kopie zu erzeugen ist auch nicht sonderlich anspruchsvoll. Gerade bei Sammlungen reicht ein .ToList oder .ToArray und schon übergibt man eine Kopie. Es ist halt nur nicht per Schlüsselwort, sondern als explizite Funktion.

Und ByRef ist abstrakter als es aussieht. Es sind eben nicht nur die Daten selbst, es ist der Zeiger auf diese Daten, der übergeben wird. Wenn ein Referenztyp mit ByVal übergeben wird, werden auch die Daten selbst übergeben, aber ein neuer Zeiger erstellt. Siehe diesen Unterschied auch in Post 5 nochmal dargestellt. Mit ByVal kriegst du von der neuen Liste nix mit.

John422 schrieb:

Aber das ist doch dem Aufrufenden egal, solange da nachher die Daten in Form einer Liste zurückkommen und das kommen sie doch, egal ob ich nun .Clear oder = New mache und danach befülle.

Wenn Du eine fremde Methode hast, die die Klasseninstanz per ByRef haben will, besteht immer der Verdacht, dass die Methode die vorhandene Instanz überschreibt. Das kann akzeptabel sein. Oder auch nicht. Das kommt auf die Klasse drauf an. Das ist wie bei einer klassenweiten Variable, die man per New deklariert und definiert. Von Haus aus macht VS den Vorschlag: »Mach es ReadOnly, damit niemand versehentlich die zum Start erstellte Instanz überschreiben kann.«:

John422 schrieb:

da erwarte ich
ByVal = unanhängige Kopie

Da Klasseninstanzen sehr groß sein können, würde die dauerhafte eine Kopie eines 100 MB-Monsters ggf. schnell mal zu einem Speicherproblem werden können. Und es würde sicherlich auch der Performance erheblich schaden. Das war m.E. ein Grund, warum Klasseninstanzen als Referenz/Zeiger übergeben werden. Es können eventuell auch Probleme auftreten, wenn es mehrere Objekte gibt, die automatisch erstellt werden und inhaltlich identisch sind, aber mir fällt grad kein Beispiel ein.

John422 schrieb:

Wieso nicht auch für eine ListOf (Char) die nichts anderes als eine String ist?

Frage mit falschen Voraussetzungen. Einer List(Of String) kannst Du nicht kommen mit: .Substring, StartsWith, Contains und all den anderen String-Methoden. Es ist einfach nicht das gleiche, noch nicht mal annähernd. Wenn Du es schaffst, eine Klasse zu schreiben, die von List(Of Char) erbt und sich exakt verhält wie ein String, dann poste das bitte im Sourcecode-Austausch. Ich erwarte ein brauchbares Ergebnis frühestens in einem Jahr.

@VaporiZed

Ich habe mal dein Code-Fragment aus #3 aufgegriffen und in meine "ApplicationLogger-Class" mit eingebunden.
Funktioniert nach ersten Tests super.

Wäre das so OK?
Was könnte ich ggf verbessern?

Hallo,

John422 schrieb:

Genauso ist es z.B. für eine String umgesezt.

Das ist nicht ganz richtig: Auch String ist ein Referenztyp. Allerdings sind strings immutable, also nicht veränderbar. Daher verhält sich string in diesem Fall ähnlich wie ein Werttyp, obwohl es ein Referenztyp ist.

John422 schrieb:

Wieso nicht auch für eine ListOf (Char) die nichts anderes als eine String ist?

String ist keine List(Of Char) sondern String implementiert IEnumerable(Of Char). Jede Liste ist zwar ein IEnumerable, aber nicht jedes IEnumerable auch eine Liste.