Why is Result<T>.Failure not using Exceptions rather than strings?

[vgallegob]

I wish the library used Exceptions rather than strings on Result.

Exceptions are far better for representing errors.

They can be translated, they can have parameters, thy interop very well with TryCatch, stackTraces...

Now our code is much more vervose.

Have you considered reverting this?

Thanks :)

[hankovich]

Using strings in Result instead of exceptions is an intentional choice to improve predictability and maintainability.

Why exceptions aren’t ideal here:

1. Exceptions are for unexpected failures, not business logic errors.

2. They introduce hidden control flow, making code harder to reason about.

3. Stack traces add unnecessary overhead for domain errors.

4. Result improves composability, enabling fluent error handling.

5. Explicit failures make the code clearer, while exceptions rely on documentation or runtime behavior.

Exceptions might seem less verbose, but they come at the cost of clarity and control. If debugging is a concern, stack traces can be logged separately.

More details: Stack Trace in Result.

Hope this helps! 🚀

[vgallegob]

I'm not defending throwing exceptions but returning them inside a Result failure, like lang-exctensions does by default. All the advantages you mentioned are still valid if Result actually ment Result<T, Exception>.

In my system we have domain exceptions marked as such. They are subclases of exception. This way we can handle all failures very very well. For example, exceptions can be translated to different http Results automatically.

Also, functions like TryBind would not need to take a mapping
Func<Exception, TError> by default, although you could if you wanted to.

You don't need to use StackTraces in domain errors, but sure is good to have a unified Failure representation that gives you as much information as posssible.

Strings are just not good failure representstions.

• They lack structure.
• They require internationalization!
• It's hard to swich on the type of failure.

In summary. We don't throw exceptions but return them. And it's quite verbise to be putting ", Exception>" everywhere.

PD: I like this library a lot ♥️

[hankovich]

I see what you mean, but I still don’t quite understand why exceptions need to be part of the Result. Exceptions are fundamentally designed to be thrown—they have no intrinsic value on their own.

For example, stack traces and other diagnostic details are only populated when an exception is thrown, which means returning exceptions inside Result doesn't fully utilize their intended purpose. If the goal is structured error handling, wouldn't a custom error type (e.g., Result<T, DomainError>) achieve the same result without relying on exceptions?

I get that using Exception avoids defining an explicit error type, but it also comes with drawbacks—verbosity, reliance on a type system that wasn’t meant for this, and potential misuse where an actual exception might accidentally get thrown instead of returned.

In the end, it comes down to preference, but I’d argue that keeping exceptions for truly exceptional cases and using structured error objects for domain failures leads to cleaner, more intentional code.

Curious to hear your thoughts! 🙂

[vgallegob]

I understand your point on exceptions ment to be thrown. And I agree some properties are not beeing used if the exception is not thrown. But:

• Exceptions are build in already, if we had Result and Maybe in the language we'd probably use that. Libraries and dependencies work with Exceptions. Exceptions are powerfull and familiar.

• Even if you had custom DomainError you would neet to return exceptions inside the error. Meaning, if we don't throw we need to return. So perhaps DomainError is redundant?

• Performance and Exhaustivenes wise, I would argue that throwing is the evil we are trying to erradicate, not exceptions. And we did that with Result.

• AggregateException aleady serves to collect multiple exceptions. One less feature to develop!

• ProblemDetails works with exceptions too. Consider the usefullness of having a built in shared type for errors. It's very convenient.

• Other functional libraries like lang-extension work with Exception too and they do just fine.

• Methods like TryBind, TryMap and such would become simpler, given that no mapping function is needed by default.

• Finally, I have junior developers in my team and I'm a 100% sure a simpler syntax would go a long way in understanding and using the feaure correctly. Keep things simple and not reinventing the wheel is important.

Very interesting conversation 🙂. I hope we can agree that choosing strings was not the best option!

I know this is a big ask, and many people are already using this. But would you be open to changing that? It would be a breaking change, but it can be fixed easily. I would be down to help as much as needed.

[vkhorikov]

There's nothing preventing the use of Result<T, CustomException>. Result<T> is just a shortcut for Result<T, string>, which is only relevant for simple cases anyway; you'd need to use Result<T, E> in all other cases.

Just like @hankovich I'd argue that this is an improper use of exceptions for all the reasons he outlined, but then again, there's no hard rule against it in the library itself.

Even if you had custom DomainError you would need to return exceptions inside the error. Meaning, if we don't throw we need to return. So perhaps DomainError is redundant?

There's no need to have an exception inside a DomainError. A DomainError is a custom class that represents an error, with no references to exceptions.

[vgallegob]

Hey, I understand your point. It's probably more academically correct. Even if you introduce your own failure type like Error, I still tink that is much much better than string. So any improvement is wellcome.

In case a custom Error type appears I would ask for:

• A way to aggregate errors.
• Be able to sublcass the type to add my own structure.
• A short name so it's easy to construct. Error?
• A implicit operator to convert from that type to failure. operator Result(Error e) => Result.Failure(e);

So I wonder, any plans to remove string as the default? Is it something you are considering?

[vgallegob]

I was wrong language-ext uses a custom error type for it's Try monad. They do wrap exceptions inside Errors:

public static Try<A> Lift(Func<A> result) => new(() => { try { return result(); } catch (Exception e) { return FinFail<A>(e); } });

Perhaps if we let Result stay like it is now and create a new construct called Try we would not generate breaking changes. Thoughts?

[vgallegob]

Hello! Have you guys had a chance of giving this a thought?

[vkhorikov]

So I wonder, any plans to remove string as the default? Is it something you are considering?

There's a ticket for that, but no ETA for when it's going to be done.

A way to aggregate errors.

This is a useful one. The ticket also outlines a basic structure for the default error with a string Code and a string Message and Result can also support their aggregation if needed.

Be able to sublcass the type to add my own structure.

This is out of scope, though. Subclassing is difficult given all type conversion you'd need to do. Basic enumeration (by Code) is what was planned.

A short name so it's easy to construct. Error?

Yes, Error.

A implicit operator to convert from that type to failure. operator Result(Error e) => Result.Failure(e);

This is already implemented (it's a feature of Result itselt, not Error)

[emassone-coreview]

Hello

Using strings in Result instead of exceptions is an intentional choice to improve predictability and maintainability.

Why exceptions aren’t ideal here:

1. Exceptions are for unexpected failures, not business logic errors.
2. They introduce hidden control flow, making code harder to reason about.
3. Stack traces add unnecessary overhead for domain errors.
4. Result improves composability, enabling fluent error handling.
5. Explicit failures make the code clearer, while exceptions rely on documentation or runtime behavior.

Exceptions might seem less verbose, but they come at the cost of clarity and control. If debugging is a concern, stack traces can be logged separately.

More details: Stack Trace in Result.

Hope this helps! 🚀

Hello @hankovich, sometimes I also feel the need to include exceptions inside result types, mainly to give the function caller as many information as possible about what went wrong and let him decide what to do in case of failure. The point is that exceptions contain a lot of detailed and useful information about what went wrong and can be a powerful tool for debugging and investigation of failures.
Most of the dotnet sdks are exception-based, in the sense that they use exceptions instead of result types to communicate failures.

In your answer you wrote:

If debugging is a concern, stack traces can be logged separately.

So, the approach you are suggesting is logging the exceptions at the point where they are caught and then communicate the result back to the function caller using a different data structure (for instance, a plain and simple string like in Result<T>) ? To put in another way, the suggestion is to log the exception as soon as possible in the call stack and then forget about it. Did I get it right ?

Honestly, apart from the debugging, there is no value in passing around the exception classes. As you said, exceptions are basically designed to be thrown.

Thanks for the clarification.