0.2.4

What's Changed

• Add some logical chaining methods for fallible types. by @tvandinther in #8

Full Changelog: 0.2.3...0.2.4

0.2.3

What's Changed

• Add methods for conversion of Fallible value to covariant and contravariant types by @tvandinther in #7

Full Changelog: 0.2.2...0.2.3

0.2.2

Fix bug where fallible values nested in OnFail calls were being lost.

Full Changelog: 0.2.1...0.2.2

0.2.1

What's Changed

• Add test workflow by @tvandinther in #5
• Add fluent error checking and fallible chaining. by @tvandinther in #6

Full Changelog: 0.2.0...0.2.1

0.2.0

Fallible namespace changed to FallibleTypes to prevent a clash of the namespace name and static class name. This change should improve the experience with IntelliSense and imports.

0.1.5

Add implicit unwrapping and remove tuple conversion

Conversion for implicit unwrapping is added to facilitate usage in wrapper functions. The tuple conversion is also removed to better enforce the two possible states (Failed, Not Failed).

0.1.4

Chaining error messages

When dealing with an Error object, often you may want to pass the error up the call stack. As it is passed up the call stack, the level of abstraction is increased which can give increasing context to the error message. To facilitate this best practice, the Error object allows string concatenation with itself.

Fallible<User> GetUserFromDB(UserId id)
{
    if (!databaseIsConnected) return new Error("Database is not connected");
    ...
}

Fallible<User> FindUserById(UserId id)
{
    var (user, error) = GetUserFromDB(id);
    if (error) return "Could not find user: " + error;
    
    return user;
}

var (user, error) = FindUserById(id);
if (error)
{
    Console.WriteLine(error); // "Could not find user: Database is not connected"
}

Messages can also be appended by putting the string on the right hand side of the + operator.

return error + ": Could not find user";

Error message formatting

To ensure that error messages are not accidentally overwritten, directly setting the Error.Message property is not possible. If appending or prepending from the error message is not suitable, you can use the Error.Format method to format the message more comprehensively. This method functions exactly like the string.Format method and uses that in its implementation.

return error.Format("Could not find user: {0}: Aborting...", error.Message);

0.1.3

Fallible now includes a Void type that can be used to return void from a method. It does not have an accessible constructor and can only be created by using the Fallible.Return property.

public Fallible<Void> DoSomething()
{
    // Do something
    if (somethingFailed) return new Error("Something went wrong");
    
    return Fallible.Return;
}

0.1.2

• Error class now implements its own ToString method.
• New Fallible<T> Fallible.Try(Func<T> closure) method to catch exceptions and wrap them into a Fallible<T> object.

0.1.1

Update README

Include documentation