Thanks for this. It reminds me of Yegor B. "Checked-vs-unchecked" (yegor256.com/2015/07/28/checked-vs...).
I don't like the proposal of using functional to "fix the problem".
In my experience, you could use unchecked exceptions to "represent" technical issues and checked exceptions to "represent" business issues, but I'm pretty sure that even with this principle in mind we'll have questionable situations...
And maybe this is the problem: the constant search for a "rule", instead of accepting just the "principle" and allowing developers to handle that specific "situation"... freely.
Thanks for this. It reminds me of Yegor B. "Checked-vs-unchecked" (yegor256.com/2015/07/28/checked-vs...).
I don't like the proposal of using functional to "fix the problem".
In my experience, you could use unchecked exceptions to "represent" technical issues and checked exceptions to "represent" business issues, but I'm pretty sure that even with this principle in mind we'll have questionable situations...
And maybe this is the problem: the constant search for a "rule", instead of accepting just the "principle" and allowing developers to handle that specific "situation"... freely.
Hi Roberto, thanks for your point of view.
I didn't know of Yegor article and I will go to read it ASAP.
My point was not to make another rule but to invite everybody to think about the reason why they are choosing one kind of exception over the other.
As long as you (rhetorical you) know why you are doing something, to me it's ok, even if I don't agree.