This is not the reality of things though.
Check this post from Eric Lippert about how C# exceptions are usually used.
And most exceptions shouldn't even be thrown, if you, for example, supply an invalid string to a parser you ideally shouldn't get back an exception to handle (here Lippert's take.
And Eric Lippert was a part of C# design team.
The result pattern still makes sense for some use cases (for other TryDoSomething is better, for other Exception handling is the way to go), even in a language like C#.
Assuming Exceptions are always the way to go seems like a good recipe for sub-optimal design choices.
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.
This is not the reality of things though.
Check this post from Eric Lippert about how C# exceptions are usually used.
And most exceptions shouldn't even be thrown, if you, for example, supply an invalid string to a parser you ideally shouldn't get back an exception to handle (here Lippert's take.
And Eric Lippert was a part of C# design team.
The result pattern still makes sense for some use cases (for other TryDoSomething is better, for other Exception handling is the way to go), even in a language like C#.
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, 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...