If there were no built-in exceptions, you would be right - a result could be anything. That isn't the case, so a result in anything - it is the happy path. Everything else is an exception. Exceptions can have types and data...
The whole purpose of this article is to advocate a Result type as an alternative to exceptions. Like exceptions, they also have a type and associated data. But yes, they do not make sense in a language with exceptions.
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.
If there were no built-in exceptions, you would be right - a result could be anything. That isn't the case, so a result in anything - it is the happy path. Everything else is an exception. Exceptions can have types and data...
The whole purpose of this article is to advocate a Result type as an alternative to exceptions. Like exceptions, they also have a type and associated data. But yes, they do not make sense in a language with exceptions.
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
TryDoSomethingpattern if we could throw everything out and redo it, but we can't. So, introducing a Result type means that we now have: exceptions, theTryDoSomethingpattern, 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...