ITLab.Template.DevPack.Core

Implements the Result pattern (railway-oriented programming) for explicit success/failure modeling without exceptions.

Namespace canônico: using ITLab.Template.DevPack.Core;

Esta área agrupa primitivos Result, Result<T>, Error, ErrorType, ValidationError. Folder e namespace alinhados (renomeados de Results/ → Core/ em 10.3.0).

Componentes

Tipo	Nome	Responsabilidade
Class	Result	Non-generic result carrying success state and an optional Error
Class	Result<T>	Generic result carrying a typed value on success or an Error on failure
Record	Error	Immutable error value with code, description and ErrorType classification
Enum	ErrorType	Categorizes failures: Validation, NotFound, Unauthorized, Conflict, Failure, Problem
Sealed Record	ValidationError	Specialized Error subtype carrying field-level validation failures

Como usar

// Return failure from a handler without throwing.
if (order is null)
    return Error.NotFound("Order.NotFound", $"Order {id} does not exist.");

// Compose results with implicit conversion.
Result<Order> result = await repository.FindAsync(id);
if (result.IsFailure)
    return result.Error;

// Create a validation error with field details.
return new ValidationError("Order.InvalidTotal", "Total must be greater than zero.",
    new[] { new ValidationFailure(nameof(command.Total), "Must be > 0") });

Error factory methods

Lista canônica das factories de Error. O HTTP mapping default refere-se ao comportamento de Result.ToHttpResult() em Extensions/ResultHttpExtensions.cs (DevPack 10.3.0+).

Factory	ErrorType	HTTP mapping (default)
Error.Validation(code, description, propertyName?)	Validation	400
Error.NotFound(code, description)	NotFound	404
Error.Unauthorized(code, description)	Unauthorized	403
Error.Conflict(code, description)	Conflict	409
Error.Failure(code, description)	Failure	500
Error.Problem(code, description)	Problem	500

Result<T> e Error têm conversões implícitas — em um método que retorna Result<XResponse>, tanto return new XResponse(...); quanto return Error.NotFound("Code", "Description"); compilam.

O que não fazer

• Do not throw exceptions for expected application failures — return Result or Result<T> instead.
• Do not inspect Result.Value without checking IsSuccess first.
• Do not use ErrorType.Failure as a catch-all; pick the most specific category.

Extensão pelo produto

• Products map ErrorType values to HTTP status codes in the API problem-details middleware.
• Products can extend Error with product-specific error factories while keeping the base Error type stable.