*@Larry Garfield*, about lack of generics in PHP you are right, but my proposal is NOT trying to solve generics, it’s trying to solve " *fragmentation*"...
Right now, every library reinvents its own Result/ErrorBag. Even if imperfect, a shared interface (like PSR‑3) would reduce duplication and improve interoperability. Also runtime overhead is minimal compared to the clarity gained(specially with current hardware and I/O). I see this as a "baseline contract" rather than a perfect solution; similar to how PSR‑3 gave us a common logger interface "without solving structured logging" *@**Korvin Szanto*, Thanks, AFAIK PHP-FIG already standardizes APIs that rely on phpdoc typing and runtime contracts. (mostly) This PSR follows the same precedent. Like: In PSR-7 we have ServerRequestInterface::getParsedBody(): mixed In PSR-18 we have sendRequest() that returning interface without generics etc... So since PHP lacks native generics, so this new PSR follows existing FIG practice: phpdoc generics plus runtime invariants. A Result is either success or failure by construction; mixed typing is not allowed. Implementors are not expected to create a class per result—one implementation per library is sufficient. I’ll align the META to make this explicit and consistent with the PR. Added a section in meta document: https://github.com/php-fig/fig-standards/pull/1344/files#diff-99b9802e69456918264b6be5f78aa91cffedf996d1fe910b0e817c4d30d9be72R81 On Tuesday, December 16, 2025 at 11:30:42 PM UTC+3:30 Korvin Szanto wrote: On Sun, Dec 14, 2025, 10:34 AM Yousha Aleayoub <[email protected]> wrote: 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 <https://groups.google.com/d/msgid/php-fig/ed4abd14-7f0c-4559-988c-8afd04538be3n%40googlegroups.com?utm_medium=email&utm_source=footer> . Thanks for putting this and the PR together. I definitely think this would be a good thing to have, but I agree with Larry that the lack of generics makes this challenging. The solution you provide in this thread is different than whats presented in https://github.com/php-fig/fig-standards/pull/1344 . Can you clarify what you intend to do to avoid the mixed typing for both success and failure? Are you thinking an implementor would provide a different result class for each possible result? Thanks, Korvin -- 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/2f7364d1-1c8d-48c0-b8f3-6ee792db2ae3n%40googlegroups.com.
