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
DefaultResultStatustoResultStatus: The concrete implementation ofIResultStatushas been renamed fromDefaultResultStatustoResultStatus. This change simplifies the naming convention and makes it more intuitive for users, reflecting its primary role as the standard status object. -
Refined
ErrorInfoMessage Retrieval inResult<T>: The lazy evaluation of theErrorproperty 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
ValueHandling inResult<T>.FailureFactory Methods: AllResult<T>.Failurefactory methods now explicitly accept aT? valueparameter. 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
ResultExceptionforThrowIfFailure: 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>.FailureOverloads:- The
Failure(T? value, IEnumerable<ErrorInfo> errors, IResultStatus status)method now includes explicitGuardclauses to preventnullor emptyerrorscollections, enhancing robustness and preventing invalid result states. - The error message for
ArgumentExceptionnow correctly states "Error messages cannot be null or empty."
- The
-
Enhanced
ResultStatusEquality:ResultStatusnow 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 whenTis 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.
-
ErrorCategoryEnum: 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. -
ErrorInfoStruct: A lightweight, immutable structure for detailed error representation, includingCategory,Code,Message, optionalData, andInnerErrorsfor nested error scenarios.- Provides a static
Aggregatemethod for creating validation-relatedErrorInfoinstances.
- Provides a static
-
IResultStatusInterface &DefaultResultStatusStruct: Defines a standard for representing the status of an operation with aCode(intended to align with HTTP status codes) andDescription.-
DefaultResultStatusprovides a concrete implementation and aCustomstatic method for creating custom statuses.
-
-
IResultInterface: Defines the fundamental contract for an operation result, providing properties to check forIsSuccessorIsFailure, accessErrors,Messages, a singleErrormessage, and theStatusof the operation. -
Result<T>Struct: A generic, immutable struct representing an operation result that can carry aValueupon success.-
Success Factory Methods:
Success,Created, andNoContentfor common successful outcomes. -
Failure Factory Methods:
Failure(for single or multiple errors),Validation,FromException,Unauthorized,Forbidden,NotFound,Conflict, andInternalErrorfor various failure scenarios. -
Monadic Operations: Includes
Map,Bind,Tap,OnSuccess, andOnFailurefor 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:
Matchmethod allows for elegant handling of success and failure branches. -
Implicit Conversion: Supports implicit conversion from
TtoResult<T>for concise success returns.
-
Success Factory Methods:
-
ResultStruct (Non-Generic): A non-generic version ofResultfor 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
ErrorInfofor direct error returns.
- Provides similar success and failure factory methods as
-
ResultJsonConverter: CustomJsonConverterFactoryto enable proper JSON serialization and deserialization ofResultandResult<T>types, ensuringIsSuccess,IsFailure,Status,Messages,Errors, andValue(forResult<T>) are correctly handled. -
ResultStatusesClass: A static class providing a comprehensive collection of predefinedIResultStatusinstances, 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 anIResultStatusto its integer HTTP status code.