These methods are available:

For almost every method you can override the default status codes for Success/Failure.

All methods are available in sync and async variants.

By default, failures get mapped to a ProblemHttpResult based on RFC9457. The status property contains the status code. The type property contains a URI to the corresponding RFC9110 entry based on the status code. The title property contains a generic short messages based on the status code. The detail property contains the error property of the Result.

If you want your own mapping logic read on.

Custom errors

This library uses a Source Generator to generate extension methods for your own custom error types when using Result<T,E> or UnitResult<E>.

1. First create a custom error type public class UserNotFoundError { public required string UserId { get; init; } }
2. Create a mapper that implements IResultErrorMapper which maps this custom error type to an IResult that you want to return in your WebAPI: public class UserNotFoundErrorMapper : IResultErrorMapper<UserNotFoundError, ProblemHttpResult> { public Func<UserNotFoundErrorMapper, ProblemHttpResult> Map => error => { var problemDetails = new ProblemDetails { Status = 404, Title = "User not found", Type = "https://tools.ietf.org/html/rfc9110#section-15.5.5", Detail = $"The user with ID {error.UserId} couldn't be found. }; return TypedResults.Problem(problemDetails); }; }
3. Use the generated extension method: app.MapGet("/users/{id}", (string id) => { return userRepository.find(id) //Result<User,UserNotFoundError> .ToHttpResult(); });

Make sure that every custom error type has exactly one corresponding IResultMapper implementation. Otherwise, the build might fail with diagnostic error CFEMAPI002.

If extension methods for custom errors are missing, rebuild the project to trigger Source Generation.

Optionally, there is a helper method ProblemDetailsMap.Find() to find a suitable title and type for a status code based on RFC9110.