Esta página ainda não foi traduzida, por isso é exibida em inglês. Ajude a traduzir

RxDart vs FxDart › #13 · Keep values AND failures in the audit

Keep values AND failures in the audit

FxDart wins

• fx
• map
• partition

Requirement

A deploy audit parses eight key=value config lines, three of which have unparseable values. The report needs both halves: print each successfully parsed key = value, then a count of the failures. The lines are in the code; both versions must print the output shown under Expected output.

timeout = 30
port = 8080
workers = 4
ttl = 300
batch = 25
failures: 3

Side by side

Why they differ

The stream model carries errors on a separate, out-of-band channel — and that channel is terminal: one FormatException ends the whole subscription, taking the five good lines with it. To keep values and failures, the RxDart side has to give every line its own inner stream (Rx.fromCallable) and convert the error into data before it can escape — onErrorReturn(null) here, with null standing in for "this one failed". That is the lightest spelling the model allows for a throwing function (the heavier materialize route reifies full notification objects), and it exists only to undo a decision the model made for you: errors were never values to begin with. (Both panels share the same throwing parse on purpose — with a null-returning parser both models could keep outcomes as plain data; the throw is the premise, and what each side must do about it is the comparison.)

The pull side never puts failures on a channel in the first place. The same throw lands one local try/catch away from being an ordinary value again — a nullable record — so the whole requirement is map then partition: one pass, two lists, both halves equally first-class. This is the shape of FxDart's broader typed-errors stance (its Either pipelines are this same idea with richer error types). When failures are part of the report rather than an exceptional end, keeping them as data wins — the verdict goes to FxDart.