Vorgehensweise Umgang mit Fehlern MVVM

Hi, wie wäre für folgendes der richtige Weg?

In einer MVVM-Anwendung würde aus der Businesslogik heraus eine Methode in einer Klasse für einen Datenimport per CSV aufgerufen. Diese ist für das Laden und das Aufbereiten der Daten zuständig. Nun können da ja verschiedene Fehler passieren:

- Datei nicht zugreifbar
- Daten nicht auswertbar
- Version der Datendatei veraltet

Bei manchen dieser Fehler würde eine Exception auslösen und wird daher mit einem Try/Catch abgefangen, andere würden per Code bei der Auswertung entstehen.

Wie wird nun die BL und der Anwender über diese Fehler informiert? In der CVS-Laden-Klasse sollen keine MsgBoxen und sowas enthalten sein.

Möglichkeiten wären meiner Meinung nach:
- Rückgabewert über Enum
- Exceptions und eingene Exceptions
- ?

Wie sieht das aus wenn ein Backgroundworker verwendet wird was durchaus sinnvoll ist?

Gruß

So strikt würde ich es jetzt nicht unbedingt machen. Bei API's und größeren Projekten handhaben wir es meist so, dass jede Methode der BusinessLogik einen entsprechenden Rückgabetyp hat.

Für das lesen von Daten aus der Datenbank beispielsweise etwas wie:

C#-Code:

public class GetUserDataResult {       ///       // Gets or sets if getting user data succeeded       ///       public bool Success { get; set; }       ///       // Gets or sets the error text if the data call failed       ///       public string Error { get; set; }       ///       // Gets or sets the user data       ///       public UserData UserData { get; set } }

Success und Error kommen hier natürlich aus einer gemeinsamen Basisklasse für Aufrufergebnisse.

Klar würde es auch mit Exceptions bis Stelle x ausreichen. Wir reden aber im von CodeF genannten Fall von erwarteten Fehlern die auch entsprechend behandelt werden sollten.

Bei APIs macht man das aufgrund vom Technologiebruch, zB .NET auf JSON.
Bei APIs ohne Technologiebruch bzw. ohne Auswirkung des Bruchs wie zB WCF oder gRPC, macht man das i.d.R. nicht.

Wenn also kein Workaround notwendig ist, dann ist so ein vorgehen unnütz bzw. Kontraproduktiv.

Eine solche Klasse in der Business Logik stufe ich persönlich als großen Designfehler ein.
Er bricht klar die Empfehlungen und Prinzipien von Software Architektur in dem Bereich.

Eine Exception kann sowohl erwartet als auch unerwartet sein.

Die unerwarteten Exceptions sollten nicht gefangen oder zumindest weiter geworfen werden.

Die erwarteten Exceptions sollte man erst dann fangen, wenn man sie auch wirklich behandeln kann. Sie vorher abzufangen und mit weniger Infos in ein eigenes Objekt zu packen, macht meiner Meinung nach überhaupt keinen Sinn.

Ich denke so darüber, dass man den Backgroundworker prinzipiell gar nicht mehr braucht, da es mittlerweile eben Tasks gibt, die quasi jeden Verwendungszweck des Backgroundworkers übernommen haben.

Rein prinzipiell kann man aber auch mit dem Backgroundworker so programmieren, das das Handhaben von Exceptions kein Problem ist.
Das ist dann "einfach" das Thema von Software Architektur und der Anwendung von Code Pattern.

Im einfachsten Falle gibt es dafür Events.

Der BackgroundWorker allerdings ist ein schlechtes Beispiel. - Denn im WorkerCompleted musst du keine weitere Exception werfen. Du kannst den Fehler direkt auswerten und in irgend einer Art und Weise ausgeben.