Changelog - ulfbou/Zentient.Results GitHub Wiki
This release introduces significant enhancements to the Zentient.Results
library, focusing on improved consistency, robustness, and internal clarity. Key updates include renaming DefaultResultStatus
for better alignment, refining the ErrorInfo
message retrieval, and enhancing the Result<T>
structure for more explicit value handling.
-
Renamed
DefaultResultStatus
toResultStatus
: The concrete implementation ofIResultStatus
has been renamed fromDefaultResultStatus
toResultStatus
. This change simplifies the naming convention and makes it more intuitive for users, reflecting its primary role as the standard status object. -
Refined
ErrorInfo
Message Retrieval inResult<T>
: The lazy evaluation of theError
property inResult<T>
has been enhanced. It now prioritizesErrorInfo.Message
, thenErrorInfo.Code
, and finallyErrorInfo.Data.ToString()
for a more robust and predictable retrieval of the primary error message when multiple pieces of information are available. -
Explicit
Value
Handling inResult<T>.Failure
Factory Methods: AllResult<T>.Failure
factory methods now explicitly accept aT? value
parameter. This allows for scenarios where a default or partially constructed value might still be useful even in a failed result, providing more flexibility in error handling pipelines. -
Introduced
ResultException
forThrowIfFailure
: A new custom exception type,ResultException
, has been introduced. This exception is specifically thrown by theThrowIfFailure()
extension method (which now lives inResultExtensions
), providing a structured way to exposeIReadOnlyList<ErrorInfo>
when a result is forcibly unwrapped on failure. -
Improved Error Handling in
Result<T>.Failure
Overloads:- The
Failure(T? value, IEnumerable<ErrorInfo> errors, IResultStatus status)
method now includes explicitGuard
clauses to preventnull
or emptyerrors
collections, enhancing robustness and preventing invalid result states. - The error message for
ArgumentException
now correctly states "Error messages cannot be null or empty."
- The
-
Enhanced
ResultStatus
Equality:ResultStatus
now explicitly implementsIEquatable<ResultStatus>
, ensuring correct and consistent value equality comparisons for result statuses throughout the application. -
Added
Result<T>.NoContent()
Factory Method: A new static factory methodResult<T>.NoContent(string? message = null)
has been added for generic results. This provides a clear and consistent way to indicate a successful operation with no content, aligning with HTTP 204 No Content semantics, particularly useful whenT
is a value type or when an empty value is ambiguous.
This is the inaugural release of the Zentient.Results library, providing a robust and flexible framework for handling operation outcomes with explicit success and failure states.
-
ErrorCategory
Enum: Introduced a comprehensive set of predefined error categories to classify different types of operation failures, includingGeneral
,Validation
,Authentication
,Authorization
,NotFound
,Conflict
,Exception
,Network
,Database
,Timeout
,Security
, andRequest
. -
ErrorInfo
Struct: A lightweight, immutable structure for detailed error representation, includingCategory
,Code
,Message
, optionalData
, andInnerErrors
for nested error scenarios.- Provides a static
Aggregate
method for creating validation-relatedErrorInfo
instances.
- Provides a static
-
IResultStatus
Interface &DefaultResultStatus
Struct: Defines a standard for representing the status of an operation with aCode
(intended to align with HTTP status codes) andDescription
.-
DefaultResultStatus
provides a concrete implementation and aCustom
static method for creating custom statuses.
-
-
IResult
Interface: Defines the fundamental contract for an operation result, providing properties to check forIsSuccess
orIsFailure
, accessErrors
,Messages
, a singleError
message, and theStatus
of the operation. -
Result<T>
Struct: A generic, immutable struct representing an operation result that can carry aValue
upon success.-
Success Factory Methods:
Success
,Created
, andNoContent
for common successful outcomes. -
Failure Factory Methods:
Failure
(for single or multiple errors),Validation
,FromException
,Unauthorized
,Forbidden
,NotFound
,Conflict
, andInternalError
for various failure scenarios. -
Monadic Operations: Includes
Map
,Bind
,Tap
,OnSuccess
, andOnFailure
for functional-style composition and error handling. -
Value Retrieval:
GetValueOrThrow()
,GetValueOrThrow(string message)
,GetValueOrThrow(Func<Exception> exceptionFactory)
, andGetValueOrDefault(T fallback)
for safe or explicit value access. -
Pattern Matching:
Match
method allows for elegant handling of success and failure branches. -
Implicit Conversion: Supports implicit conversion from
T
toResult<T>
for concise success returns.
-
Success Factory Methods:
-
Result
Struct (Non-Generic): A non-generic version ofResult
for operations that do not return a specific value, but still convey success or failure.- Provides similar success and failure factory methods as
Result<T>
. - Includes implicit conversion from
ErrorInfo
for direct error returns.
- Provides similar success and failure factory methods as
-
ResultJsonConverter
: CustomJsonConverterFactory
to enable proper JSON serialization and deserialization ofResult
andResult<T>
types, ensuringIsSuccess
,IsFailure
,Status
,Messages
,Errors
, andValue
(forResult<T>
) are correctly handled. -
ResultStatuses
Class: A static class providing a comprehensive collection of predefinedIResultStatus
instances, largely mapping to standard HTTP status codes (e.g.,Success
(200),Created
(201),BadRequest
(400),Unauthorized
(401),NotFound
(404),InternalError
(500)). -
ResultStatusExtensions
: An extension methodToHttpStatusCode()
for converting anIResultStatus
to its integer HTTP status code.