Exception handling is a critical aspect of software development, and C# provides powerful mechanisms to handle and propagate exceptions. However, what if there was an alternative approach that allows us to return exceptions instead of throwing them? Is there a better way than try, catch, throw, handle, maybe rethrow, etc… Can we find an alternative way? I’ve always found myself dealing with unstructured data as input in the applications I’ve had to build. Whether that’s handling user input or writing complex digital forensics software to recover deleted information for law enforcement. I wanted to take a crack a solving this with some of the things I had dabbled with regarding implicit conversion operators. I created a class called , that can represent either a value or an exception, providing more control over error handling and control flow. In this blog post, we’ll explore how I use and how it helps me with cleaning up my code while offering more failure details than a simple boolean return value for pass or fail. It might not be your cup of tea, but that’s okay! It’s just another perspective that you can include in your travels. TriedEx<T> TriedEx<T> Implicit Operator Usage Before diving into the specifics of , let’s recap . In the , we explored how implicit operators allow for seamless conversion between different types. This concept also applies to . By defining implicit operators, we can effortlessly convert between , , and types. This flexibility allows us to work with instances as if they were the underlying values or exceptions themselves, simplifying our code and improving readability. TriedEx<T> the concept of implicit operators previous blog post TriedEx<T> TriedEx<T> T Exception TriedEx<T> And the best part? If we wanted to deal with exceptional cases, we could avoid throwing exceptions altogether. You can check out this video for more details about implicit operators as well: https://youtu.be/Uod7_hSG6zM?embedable=true Pattern Matching with Match and MatchAsync A key feature of is the ability to perform pattern matching using the and methods. These methods enable concise and expressive handling of success and failure cases based on the status of the instance. Let’s look at some examples to see how this works. TriedEx<T> Match MatchAsync TriedEx<T> In the following example, we’ll assume that we have a method called that will be able to handle exceptional cases for us. And before you say, “Wait, I thought we wanted to avoid throwing exceptions!” I’m just illustrating some of the functionality of to start: Divide TriedEx<T> TriedEx<int> result = Divide(10, 0);

result.Match(
    success => Console.WriteLine($"Result: {success}"),
    failure => Console.WriteLine($"Error: {failure.Message}")
); In the above example, the method takes two lambda expressions: one for the success case (where the value is available) and one for the failure case (where the exception is present). Match Depending on the state of the instance, the corresponding lambda expression will be executed, allowing us to handle the outcome of the operation gracefully. TriedEx<int> If you’d like to be able to return a value after handling the success or error case, there are overrides for that as well: TriedEx<int> result = Divide(10, 0);

var messageToPrint = result.Match(
    success => $"Result: {success}"),
    failure => $"Error: {failure.Message}")
);

Console.WriteLine(messageToPrint); Similarly, the method provides the same functionality but allows us to work with asynchronous operations. This is particularly useful when dealing with I/O operations or remote calls that may take some time to complete. MatchAsync Deconstructor Usage Another feature of is its . Deconstruction enables us to extract the success status, value, and error from a instance in a convenient and readable way. Let’s take a look at an example: TriedEx<T> support for deconstruction TriedEx<T> TriedEx<string> result = ProcessInput(userInput);

var (success, value, error) = result;

if (success)
{
    Console.WriteLine($"Processed value: {value}");
}
else
{
    Console.WriteLine($"Error occurred: {error.Message}");
} In this example, the deconstruction pattern is used to unpack the success status, value, and error from the instance. By leveraging the deconstruction syntax, we can access these components and perform the appropriate actions based on the outcome of the operation. TriedEx<string> Practical Example: Avoiding User Input Exceptions If you’re interested in seeing practical examples of how this class can be used, check out the full blog post! More code examples are included to walk you through how this design has helped me clean up my exception-handling code. Remember to for a quick 5-minute read every weekend! This includes content summaries, other learning resources, and community spotlights as well. Thank you for your support! subscribe to my newsletter Also published as a full article. here

This story contains new, firsthand information uncovered by the writer.

How To Master Plugin Architecture in ASP.NET Core

Choosing the Best Beginner Programming Language

Newsletter

Portfolio

Too Long; Didn't Read

Make resilience your competitive advantage

Exception Handling: Breaking Free From Exceptions, A New Way Forward

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

3 Beginner Tips You Need to Know for async await in C#

5 Performance Tips For .Net Developers

6 Best C# Programming Books Ranked by Review Score

7 C# Tips for Beginners in Programming Language

A Beginner's Guide Formatting Strings as Base64 in CSharp

3 Beginner Tips You Need to Know for async await in C#

5 Performance Tips For .Net Developers

6 Best C# Programming Books Ranked by Review Score

7 C# Tips for Beginners in Programming Language

A Beginner's Guide Formatting Strings as Base64 in CSharp

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps