op_result 0.4.0

A generic result type for handling success and error cases in a type-safe manner.

0.4.0 - 2026-03-15

Improvements

• Added structured error details to OpError

  • OpError can now carry additional contextual data through a new details map.
  • This enables richer error handling without making the package application-specific.
  • Typical use cases include context, translation placeholders, counts for pluralization, field names, backend status codes, etc.

• Added typed detail lookup support

  • Introduced detailAs<T>(String key) to safely read typed values from OpError.details.

• Added hasDetails helper to OpError

  • Makes it easier to check whether an error carries extra contextual information.

• Added copyWith() to OpError

  • Allows creating modified copies of an existing error while preserving the rest of its data.

Maintenance

• Improved immutability guarantees

  • OpError.errorMap and OpError.details are now stored as unmodifiable maps.
  • OpResult.errors is now exposed as an unmodifiable list.

• Improved diagnostics

  • OpError.toString() now includes structured error details for easier debugging.

• Improved API robustness

  • Accessing OpResult.error on a successful result now throws a clear StateError.

Notes

• This release is backward-compatible for existing code that does not use details.
• OpResult<T> remains untyped on the error family, preserving the package's flexibility across layers and use cases.

0.3.1 - 2025-04-25

Maintenance

• Fixed outdated samples previously in the README.
• Moved all README code samples into example/op_result_example.dart for easier maintenance.
• Added automated test test/op_result_example_test.dart to ensure examples stay valid and error-free.
• No functional changes to the library code.

0.3.0 - 2025-03-01

Breaking Changes

• Refactored OpResult<T> to remove E extends Enum

  • OpResult no longer requires an error type at the class level. Errors are now enforced as enums only at failure creation.
  • Before:

  OpResult<T, E extends Enum>
  

  • Now:

  OpResult<T>
  

  • This allows returning any error type (e.g., validation and API errors) in the result.

• Breaking change in failure() constructor

  • failure() only accepts a single error.
  • multipleFailures() must be used to pass a list of errors.
  • Before:

    OpResult.failure([error1, error2]); 
    

  • Now:

    OpResult.multipleFailures([error1, error2]); 
    

  • This ensures strong typing while allowing flexibility in OpResult.

• Breaking change: OpResultError has been renamed to OpError.

0.2.2 - 2025-02-28

Maintenance

• Bumped version to 0.2.2 for consistency and dependency updates.
• No functional changes.

0.2.1 - 2025-02-28

Initial Public Release

• Added support for nullable success values (T?) in OpResult.success()
• Improved failure handling by supporting both single and multiple errors
• Refactored OpResult.success() to use a positional argument instead of a named parameter

0.2.0 - 2025-02-27

Breaking Changes

• Refactored OpResult.success() to use a positional argument instead of data:
  • Now, call OpResult.success(value) instead of OpResult.success(data: value).
  • Example:
    • Before: OpResult.success(data: user);
    • Now: OpResult.success(user);
• Refactored OpResult to support multiple errors:
  • Replaced _error (single error) with _errors (list of errors).
  • OpResult.failure() now supports both single and multiple errors via a factory constructor:
    • OpResult.failure(singleError)
    • OpResult.failure([multipleErrors])

Improvements

• Unified failure handling:
  • Removed OpResult.failure({required OpResultError<E> error}) in favor of a flexible factory constructor.
  • Supports passing either a single error or a list of errors dynamically.
• Ensured failure() cannot receive an empty list, preventing invalid states.
• Refactored error access:
  • error → Returns the first error (default for single-error scenarios).
  • errors → Provides full access to all errors when multiple exist.

0.1.0 - 2025-02-26

• Initial version.