👋 Open question: At which point do you wrap kotlin exceptions into a sealed class / Either / exception wrapper?
ViewModel, Interactor, Repository, DataSource, ASAP? I feel at least the exception shouldn’t reach the View layer.
^^ exactly that
Also, it's likely best to start in the lowest layer/data source. Explicitly using the type system is much safer than using vague unchecked exceptions that subvert your dataflow.
a
Adam Powell
07/15/2020, 7:22 PM
At the point where the exceptional condition needs to be represented as a state rather than an event. This generally meets your intuition of, "shouldn't reach the view layer," as by the time you're producing content to be shown in views, you are working with state that will persist until something else happens to it.
and it often means that the translation can happen somewhere in the middle of your data pipeline: "data is unavailable and here is why" is a state; a network exception that cancelled a specific data fetch is an event.
☝️ 1
You can certainly dial that all the way to monads everywhere if you feel so inclined, but after taking that approach in several codebases in a few different languages, I find that after a while I take a step back and have to acknowledge that it made the code harder to read and understand. YMMV.
a
allan.conda
07/16/2020, 5:26 AM
Thanks for your input! I’d have to read further including that article to form my opinion