Well, just going to throw my rule of thumb in there.
I tend to use the Result type in asynchronous code and Throws in things that execute tmmediately.
I find Result much cleaner than the old returns of callbacks, which tended to be 2 optionals, the succesful result, or the error, or worrse, both or neither.
I won’t deny it can’t be abused to make things worse, i complained to a supplier on making a throwable combine publisher.
> I tend to use the Result type in asynchronous code and Throws in things that execute tmmediately.
Sure, but then you have to have a crystal ball to know which functions will or won't ever be called asynchronously. It drives me nuts that a function should have to know how, when, or where it's going to be called.
It doesn't help that working with Result is generally pretty cumbersome (flatMap only gets you so far- you'll either end up with deeply nested (flat)Map chains or have a bunch of switch statement noise).
So, for a while I used to just always prefer returning Result for everything, since it was guaranteed to "work" for both async and sync operations. But, now I've gone the opposite direction. I use `throws` for all my named functions because the are so much more ergonomic to "compose" and I just wrap the call in a `Result {}` closure/lambda when I have to pass it as an async callback.
I find Result much cleaner than the old returns of callbacks, which tended to be 2 optionals, the succesful result, or the error, or worrse, both or neither.
I won’t deny it can’t be abused to make things worse, i complained to a supplier on making a throwable combine publisher.