Hello, I’m submitting for discussion and vote a new PSR proposal to address a long-standing gap in PHP’s *error-handling* ecosystem:
Standard Interfaces for Recoverable Errors and Operation Results *(Working title: PSR-XX Error and Result Interfaces)* *The problem* PHP *forces *developers to choose between two flawed patterns for non-exceptional failures: - Throwing exceptions for expected outcomes (like validation errors, cache misses) -> breaks control flow, hurts performance, and conflates recoverable vs. unrecoverable errors. - Returning ambiguous values (null, false, ['error' => ...]) → destroys type safety and forces brittle checks across the call stack. Frameworks and libraries reinvent this wheel constantly: - Laravel’s ValidationException - Symfony’s ConstraintViolationList - Guzzle’s TransferException + status codes - Custom Result<bool, string> classes in libraries... There is no interoperable, type-safe way to return structured, recoverable errors. *The Solution* This PSR will propose three minimal, zero-dependency interfaces: 1. ResultInterface: a sealed union for success/failure states 2. SuccessInterface: wraps a successful value 3. FailureInterface: wraps structured error data (code, message, context) and optionally a Throwable *Key features* - No exceptions required for expected failures! - Immutable, readonly objects - Pattern-matchable via isSuccess()/isFailure() - Composable with PSR-3 (logging), PSR-11 (containers), *and async runtimes* - Zero runtime overhead – pure interfaces, no DI or middleware Thanks for your time. -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/php-fig/ed4abd14-7f0c-4559-988c-8afd04538be3n%40googlegroups.com.
