A Failable<T> that allows safe returning of exceptions

Question

This was inspired by a conversation in chat, that started with the discussion of C#7.0 tuples and out parameter declarations, which led to the idea that there is no 'good¹' way to return an error state in C# without throwing an exception.

Out of curiosity, I wondered what it would take to design a type that was transparent to the developer, but allowed them to safely return exceptions without having to unwind the stack.

For those who don't know, when you throw/catch Exception objects in C# (or VB.NET, F#, any .NET language follows the same requirements), the most expensive part tends to be the stack. Throwing an exception is cheap, but catch the exception and the stack has to unwind and reflect against itself to give you the information you need. This is by-design, of course. The language and framework designers wanted exceptions to mean that the program entered an 'exceptional state', that is, there is an issue that needs resolved.

The problem is that some methods don't really need to throw an exception on error, they could, instead, just return a pass/fail and then fill an out parameter. The other option is to return a Tuple<bool, T>, where T is the return type.

Of course, this doesn't give us the ability to return an Exception, just pass/fail. Sometimes we may want to return what went wrong.

So, alas, I get to the Failable<T> struct that I created today. By including implicit conversions to and from T and Exception, it allows us to simply return Exception instead of throwing, creating a much cheaper management of error states.

The only caveat to this approach from a usability standpoint, is that one does not simply define an implicit conversion from null. This means that Failable<string> value = null; is invalid, but Failable<string> value = (Failable<string>)null; is, as well as Failable<string> value = new Failable<string>(null);.

If the framework/language designers ever open up implicit conversions from null, then this struct would be completely transparent.

public struct Failable<T> : IEquatable<Failable<T>>
{
    public Exception Exception { get; }
    public T Result { get; }
    public bool Passed { get; }

    private Failable(Exception exception, T result, bool passed)
    {
        Exception = exception;
        Result = result;
        Passed = passed;
    }

    public Failable(Exception exception)
        : this(exception, default(T), false)
    {
    }

    public Failable(T result)
        : this(null, result, true)
    {
    }

    public static implicit operator Failable<T>(Exception exception) => new Failable<T>(exception);
    public static implicit operator Failable<T>(T result) => new Failable<T>(result);

    public static implicit operator Exception(Failable<T> result) => result.Exception;
    public static implicit operator T(Failable<T> result) => result.Result;

    public override string ToString() => (Passed ? Result?.ToString() : Exception?.ToString()) ?? "null";
    public override int GetHashCode() => Exception.GetHashCode() ^ Result.GetHashCode();

    public bool Equals(Failable<T> other) => this == other;
    public override bool Equals(object obj) => obj is Failable<T> && this == (Failable<T>)obj;
    public static bool operator ==(Failable<T> a, Failable<T> b) => a.Exception == b.Exception && a.Result.Equals(b.Result);
    public static bool operator !=(Failable<T> a, Failable<T> b) => a.Exception != b.Exception || !a.Result.Equals(b.Result);

    public static readonly Failable<T> Empty = new Failable<T>();
}

Now, to demonstrate how this works I defined a very ugly method, so do not review it please, that goes through all the possible features of this struct:

static Failable<T> FailableTest<T>(bool pass, bool nullOrThrow, T result)
{
    try
    {
        if (pass)
        {
            if (nullOrThrow)
            {
                // Both options are valid:
                // return new Failable<T>(null);
                return (Failable<T>)null;
            }
            else
            {
                return result;
            }
        }
        else
        {
            if (nullOrThrow)
            {
                throw new ArgumentException($"Throwing as expected, {nameof(pass)}:'{pass}', {nameof(nullOrThrow)}:'{nullOrThrow}'.");
            }
            else
            {
                return new ArgumentException($"Returning as expected, {nameof(pass)}:'{pass}', {nameof(nullOrThrow)}:'{nullOrThrow}'.");
            }
        }
    }
    catch (Exception e)
    {
        return e;
    }
}

Our test cases are something on the order of:

Console.WriteLine("Pass  : " + FailableTest(true, false, "1. String on pass").ToString());
Console.WriteLine("Fail  : " + FailableTest(false, false, "2. String on pass").ToString());
Console.WriteLine("Null  : " + FailableTest(true, true, "3. String on pass").ToString());
Console.WriteLine("Throw : " + FailableTest(false, true, "4. String on pass").ToString());
Console.WriteLine("Cast  : " + (FailableTest(true, false, 15) - FailableTest(true, false, 5)));

Returning:

Pass  : 1. String on pass
Fail  : System.ArgumentException: Returning as expected, pass:'False', nullOrThrow:'False'.
Null  : null
Throw : System.ArgumentException: Throwing as expected, pass:'False', nullOrThrow:'True'.
   at GenericFailableTest.Program.FailableTest[T](Boolean pass, Boolean nullOrThrow, T result) in c:\users\ebrown\documents\visual studio 2017\Projects\Test CSharp Projects\GenericFailableTest\Program.cs:line 44
Cast  : 10

The interesting thing about this is that the implicit operator T operator allows you to just ignore this class altogether:

var str = FailableTest(true, false, "Some String");

And this is by design, which brings me to my main list of questions:

1. Should there be a T(Failable<T>) operator? If so, should it be implicit?
2. Should there be an Exception(Failable<T>) operator? If so, should it be implicit?
3. Should the API include a Failable(Tuple<bool, T>) constructor that allows one to pass a tuple of (pass, value)? A proper definition might be:

static Failable<int> TryParse(string input)
{
    int result;

    if (int.TryParse(input, out result))
    {
        return result;
    }
    else
    {
        return new ArgumentException($"The string '{input}' was not a valid integer.");
    }
}

var parseResult = new Failable<int>();
while (!parseResult.Passed)
{
    parseResult = TryParse(Console.ReadLine());
}

var value = parseResult.Result;
// Do something with `value`

---

_{1: The term 'good' here is subjective, there are two major alternatives to throwing exceptions already present in the language:}

<sub>1. Use out parameters;
2. Return a Tuple;</sub>

_{Either of these are 'good' in certain lights; I'm simply attempting to draw out another possible alternative.}

Answer 1

First: congratulations, you have rediscovered the error monad.

https://hackage.haskell.org/package/mtl-2.2.1/docs/Control-Monad-Error.html

Second: as noted in the comments, C# already has the concept of "wrap up either a value or an exception, namely, Task<T>. You can use Task.FromException and Task.FromResult to construct them. Of course Result on the task either produces the result or throws the exception, as does await.

Also, this illustrates that there need be no asynchrony in a task! A task is just the concept of "I'll provide a value or an exception in the future if I don't already have it now". If you already have it now, great; you can use tasks to represent your "failable" concept, and await them like any other task.

Should there be a T(Failable<T>) operator? If so, should it be implicit?

Operators that convert a generic type to anything whatsoever can be difficult to reason about. Certainly it should not be implicit because the operation is not guaranteed to succeed! If you want this, it should be explicit.

Look at the design of Task for inspiration here. Notice that the factories are static methods and they are very clear when they are being called. And it is also very clear when the result is being fetched.

Similarly look at the design for nullable. (The "maybe monad" is very similar to the error monad; more on this below.) There is an implicit conversion from T to T?, but the conversion from T? to T is explicit.

Should there be an Exception(Failable<T>) operator? If so, should it be implicit?

I would find this confusing.

Should the API include a Failable(Tuple<bool, T>) constructor that allows one to pass a tuple of (pass, value)?

I don't understand the question. (Though I note that a (bool, T) tuple is the structure of the maybe monad, aka Nullable<T> in C#.)

---

Exercise 1: you have created a monad, so you should be able to define the monad operators on them; if you do so, then you can use your type in LINQ queries! Can you implement members:

struct Failable<T> ... {
  ...
  public Failable<T> Select<R>(Func<T, R> f) { ... }
  public Failable<C> SelectMany<B, C>(
    Func<T, Failable<B>> f1,
    Func<T, B, C> f2)  { ... }
  public Failable<T> Where(Func<T, bool> f) { ... }
}

If you do that, then you can write queries:

Failable<int> f = OperationThatCanFail();
Failable<double> d = from i in f where i > 0 select Math.log(i);

If you've done it right then d should be either a failure code, or the log of integer i.

---

Exercise 2: You've implemented the error monad; can you now implement the tracing monad? a Trace<T> has the value of a T, but also has an operation that appends a string to the trace, so you can track the movement of T around your program.

---

Exercise 3: nullable is implemented as a (bool, T) pair. Failable is implemented as an (Exception, T) pair. Trace is implemented as a (string, T) pair. Can you design and implement a generalized State<S, T> type which associates an S with a T, and then derive the other monads from it?

---

Finally, you might consider more advanced operations. For example:

public static Func<A, Failable<R>> ToFailable(this Func<A, R> f)
{
  return a => 
  {
    try 
    { 
      return new Failable<R>(f(a));
    }
    catch(Exception x) 
    {
      return new Failable<R>(x);
    }
  };
}

Now you can take existing functions of the form A-->R that can throw, and turn them into functions that cannot throw.

Answer 2

A few minor things:

1. You do not check for null in GetHashCode() and in equality operators. You probably should, since both Exception and Result can be null by your design.
2. You should re-use single equality implementation. For example, != should just return !(a == b).

Otherwise this implementation looks alright to me. I would probably make T conversion implicit and Exception conversion explicit (or just remove it, since you might as well just write .Exception), but that's just me not being a fan of "transparent" things. :)

P.S. Also Failable does not feel like a typical struct to me, more like a class.

Answer 3

For the sake of a consistent and discoverable API you should have a non-generic version of Failable.

For Consistency:
If I'm presented with two methods that can fail to do their job, then I'd expect to check for the success/failure in the same way. I shouldn't check result.Passed some times and result == null at other times.

For Discoverability
Using Failable as a return type clues in people that see the code that an operation is might not succeed. Using Exception as a return type misleads people that see the code that the operation has something to do with Exceptions. Given this interface with three methods that might not succeed:

public interface IYouDontKnowMyImplementation
{
    Exception AWellNamedMethod();
    Failable<T> AnotherWellNamedMethod<T>();
    Failable NamingIsHard()
}

Even if I was unfamiliar with your Failable class, at a glance I have a good chance of correctly determining what the return types of AnotherWellNamedMethod and NamingIsHard mean, but would have no reason to assume that AWellNamedMethod returns Exception because it might fail, and wouldn't expect that it returning null indicated it was successful. Which of these is easier to read and understand what is going on?

...
if(someObject.MoveFilesToArchive() == null)
{
    ...
}
if(someObject.MoveFilesToArchive().Passed)
{
    ...
}

What happens when T is Exception?

When the thing your method is supposed to do is build an exception, Your implicit conversions become ambiguous.

Failable<Exception> BuildErrorInformation()
{
    ... Do information gathering
    if(iWasAbleToGetTheInfoINeed)
    {
        return new Exception("the info I need");
    }
    else
    {
        return new Exception("I failed to get the info I needed");
    }
}

One of these code paths should produce a Failable<Exception> where

result.Exception.Message == "I failed to get the info I needed"

and one where

result.Result.Message == "the info I need"

This is really an edge case that can probably be resolved by using Failable<CustomException> instead, or just returning new Failable<Exception>(null, new Exception("the info I need"), true);

Other Comments

These might be borderline nitpicky but still earnest feedback:

• The order of parameters in function calls often carries an implied weight or importance of the parameters. As such, the choice to have the exception be the first parameter feels very odd to me.
• Consider naming the sentinel property Success or Complete instead of Passed. Almost all of the status/result/outcome codes that come to mind for conceptually similar operations use 'success' to indicate the 'good' outcome. The one place I've seen 'Passed' used is for validation of data, and even in this scenario, a 'pass' would indicate the data was good, not that the validation completed.