[Code health] Verify exceptions are either wrapped or handled in all Rx streams
See original GitHub issueWe can rename Result
to something like ValueOrError
, and wrap the value at the source, obviating the need to wrap/unwrap at arbitrary steps in the stream.
@scolsen FYI.
Issue Analytics
- State:
- Created 4 years ago
- Comments:16 (4 by maintainers)
Top Results From Across the Web
Error handling with reactive streams. | by Kalpa Senanayake
Exceptions : An exception indicates conditions that an application might want to catch and the application might be able to recover from this...
Read more >Handling Exceptions - Snowflake Documentation
In a Snowflake Scripting block, you can raise an exception if an error occurs. You can also handle exceptions that occur in your...
Read more >Error handling in RxJava - Dan Lew Codes
Even though RxJava has its own system for handling errors, checked exceptions still must be handled by your code. That means you have...
Read more >Lettuce Reference Guide
Calls to the get() method throw the occurred exception wrapped within an ExecutionException (this is different to Lettuce 3.x).
Read more >lawbook.pdf - California State Board of Pharmacy
Without Prescription: Exceptions. 4059.5. Who May Order Dangerous Drugs or Devices: Exceptions; Compliance with Laws of All Involved. Jurisdictions.
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
@scolsen, I discussed this with former teammates at FAO today (@cdanielw, @lpaolini) who work extensively with RxJS in SEPAL, and consensus is that it’s better to wrap and unwrap in some intermediate object to represent errors as a value rather than at stream level (as we have now), rather than to rely on side-effects on the inner stream, e.g.:
https://github.com/google/ground-android/blob/fd1324aa8e59159c9941c5dfab6c7c082cff0b6f/gnd/src/main/java/com/google/android/gnd/ui/projectselector/ProjectSelectorViewModel.java#L62-L67
My guess is that with some additional syntactic sugar and clearer naming we can make this more self-documenting / obvious without sacrificing FRP “purity”.
The syntax is also less verbose than the above proposed example, which may be an added bonus here.
See also big refactor PR #371 for reference.