Assuming Exceptions are always the way to go seems like a good recipe for sub-optimal design choices.
I'm saying that exceptions are the most appropriate error handling mechanism in languages that have exceptions. I'm not saying every method should throw exceptions.
I agree that a Result would be more appropriate for the TryDoSomething pattern if we could throw everything out and redo it, but we can't. So, introducing a Result type means that we now have: exceptions, the TryDoSomething pattern, and a user-defined Result type.
Having so many ways of doing similar things is a sub-optimal design choice.
You are right, you have multiple options. I think the problem is you don't distuingish between the different types of errors. Depend on that you habe to choose the correct error handling mechanism. Doing all with exceptions is Not the correct way.
I'm saying that exceptions are the most appropriate error handling mechanism in languages that have exceptions. I'm not saying every method should throw exceptions.
I agree that a Result would be more appropriate for the
TryDoSomething
pattern if we could throw everything out and redo it, but we can't. So, introducing a Result type means that we now have: exceptions, theTryDoSomething
pattern, and a user-defined Result type.Having so many ways of doing similar things is a sub-optimal design choice.
You are right, you have multiple options. I think the problem is you don't distuingish between the different types of errors. Depend on that you habe to choose the correct error handling mechanism. Doing all with exceptions is Not the correct way.
Here is a great example using Result object: jimmybogard.com/domain-command-pat...