Kann ein Rx Observable problemlos Ausnahmen in einem Operator behandeln und fortfahren?

8

d. h. durch Übergeben der Fehlerbedingung und nicht Anhalten des gesamten Observable?

Meine Beobachtungsliste beginnt mit einer vom Benutzer angegebenen Liste von Paketverfolgungsnummern aus allgemeinen Zustelldiensten (FedEx, UPS, DHL usw.), sucht online nach dem voraussichtlichen Lieferdatum und gibt diese Daten dann in Form der Anzahl der Tage ab heute zurück (also "in 3 Tagen" anstatt "22. Januar"). Das Problem besteht darin, dass, wenn eine einzelne Suche zu einer Ausnahme führt, der gesamte Stream angehalten wird und der Rest der Codes nicht nachgeschlagen wird. Es gibt keine Möglichkeit, z. B. mit UnknownTrackingCode Exception elegant umzugehen, und daher kann das Observable nicht garantieren, dass es alle vom Benutzer übermittelten Codes nachschlagen wird.

%Vor%

Das Anhalten des Observable-Streams als Folge eines Fehlers ist by design :

Das Standardverhalten kann überwunden werden, aber nur indem viele der Vorteile von Rx an erster Stelle eliminiert werden:

  • Ich kann LookupDeliveryDate so umbrechen, dass es Datumsangaben anstelle von Ausnahmen zurückgibt (z. B. 1899-12-31 für UnknownTrackingCode Exception ), aber dies verhindert "lose gekoppelten Code", da CalculateDaysFromToday diese speziellen Fälle behandeln müsste
  • Ich kann jede anonyme Funktion mit try/catch und Blöcken umgeben, aber das verhindert im Wesentlichen, dass ich lambdas
  • verwende
  • Ich kann if/thens verwenden, um den Codepfad zu steuern, aber das erfordert wahrscheinlich, dass ein Zustand beibehalten und die deterministische Auswertung eliminiert wird
  • Die Fehlerbehandlung jedes Schritts verhindert natürlich, dass alle Fehlerbehandlungen in Subscriber konsolidiert werden.
  • Das Schreiben eines eigenen Fehlerbehandlungsoperators ist möglich, aber nur wenig dokumentiert

Gibt es einen besseren Weg, damit umzugehen?

    
ExactaBox 19.01.2015, 19:17
quelle

1 Antwort

4

Was genau möchten Sie tun, wenn ein Fehler auftritt? Willst du den Eintrag einfach wegwerfen oder willst du etwas Downstream damit machen?

Wenn Sie möchten, dass etwas Downstream etwas unternimmt, dann verwandeln Sie den Fehler wirklich in Daten (eine Art Beispiel für die Rückgabe eines Sentinel-Wertes von 1899-12-31 , um den Fehler darzustellen). Diese Strategie bedeutet definitionsgemäß, dass alles Downstream verstehen muss, dass der Datenstrom Fehler statt Daten enthalten kann und dass sie modifiziert werden müssen, um damit umzugehen.

Aber anstatt einen magischen Wert zu erhalten, können Sie Ihren Observable -Stream in einen Stream von Either -Werten umwandeln. Entweder ist der Wert ein Datum oder ein Fehler. Alles Downstream empfängt dieses Either -Objekt und kann es fragen, ob es einen Wert oder einen Fehler hat. Wenn es einen Wert hat, können sie ein neues Either -Objekt mit dem Ergebnis ihrer Berechnung erzeugen. Wenn es einen Fehler gibt und sie nichts damit anfangen können, können sie einen Fehler entweder selbst verursachen.

Ich kenne die Java-Syntax nicht, aber so könnte es in c # aussehen:

%Vor%

Ihre andere Option ist das "handle" / unterdrückt den Fehler, wenn es auftritt. Dies kann je nach Ihren Bedürfnissen ausreichend sein. In diesem Fall muss LookupDeliveryDate nur magische Daten anstelle von Ausnahmen zurückgeben und dann ein .filter hinzufügen, um die magischen Daten herauszufiltern, bevor sie zu CalculateDaysFromToay gelangen.

    
Brandon 19.01.2015, 20:19
quelle