Result Pattern better support for it in the language

[paule96]

I have lately come across the idea of the Result Pattern, which is the basic idea that an Action can result only in two states: success and failure.

This is quite an interesting idea because you can handle with this pattern all the known problems that you as a programmer expect from your code to happen.

The problem with the current implementations of C# is, that there is currently not a good way to transport a problem up the call stack without:

• writing quite verbose code
• throw an expensive exception

Sample to understand the problem

using DotNext;
Console.WriteLine("Hello, World!");
var output = DoWork();
if(output.IsSuccessful){
    Console.WriteLine("Wuhu! We can calculate");
}else{
    Console.WriteLine("Arggg numbers are complicated.");
}

Result<int> DoWork(){
    Result<int> test = AddNumbers(1, 2);

    if(!test.IsSuccessful){
        // This method doesn't handle the problem. 
        // Just stops the execution and makes the problem, 
        // to a problem of someone else
        return test;
    }
    test = DivideNumbers(test.Value, 2);
    if(!test.IsSuccessful){
        // handles the problem and returns a valid result
        return 5;
    }
    // Returns the successful result
    return test;
}

Result<int> AddNumbers(int a, int b){
    if((a % 2) == 0){
        return Result.FromException<int>(new Exception("error"));
    }
    return a + b;
}

Result<int> DivideNumbers(int a, int b){
    if((a % 2) == 0){
        return Result.FromException<int>(new Exception("error"));
    }
    return a / b;
}

The problem with the code are the lines:

 if(!test.IsSuccessful){
        // This method doesn't handle the problem. 
        // Just stops the execution and makes the problem, 
        // to a problem of someone else
        return test;
    }

These lines are quite verbose and are in most cases the normal path if an error happens. Usually, errors that happen because of some invalid input or configuration will be detected only deep inside a long call stack of functions. All of these functions a probably not able to solve the problem but need to return the problem, until someone is handling the problem. (usually handling means, converting the error into something human-readable and presenting the problem to the user/client and letting it solve it)

That would result in many of these kind of blocks that makes it hard to read the code. In special if you have something like that:

var result1 = someFuncitonCall();
// check if it fails and return if needed;
var result2 = someMethodCall();
// check if it fails and return if needed;
var result3 = someMethodCall(result1.Value);
// check if it fails and return if needed;

Some Ideas for a solution

It would be nice if the caller could easily decide if he wants to handle the problem or not without being so verbose in the code.

For example, I could imagine something like a new keyword:

var result = someFunctionCall() ignore Problem;
someMethodCall() ignore Problem;
someMethodCall(result1.Value) ignore Problem;

That would mean if a problem occurs in one of the function calls it stops the execution of the current function and returns the Result that contains the Problem to the caller.
That means also that the variable result can be directly the result type instead of Result<something>.

What I have tried so far

https://github.com/dotnet/dotNext/blob/master/src/DotNext/Result.cs
https://github.com/altmann/FluentResults
https://github.com/ardalis/Result

Maybe related issue to that

#47020
#46280 -> in special the comments there

How do other solve the problem

For example rust hast the implementation of the question mark operator. You can find more about it here:

https://doc.rust-lang.org/std/result/#the-question-mark-operator-

[martincostello]

This ask sounds like it's about C#, not specific ASP.NET Core (even though that's the use case why you want such a feature).

If that's the case, then you want to find an existing issue (maybe dotnet/csharplang#113?) or open a new one in the dotnet/csharplang repository.