All PHP functions, rewritten to throw exceptions instead of returning false
2.5k
Stars
168
Forks
34
Open issues
30
Contributors
AI Analysis
Safe PHP is a library that wraps core PHP functions to throw exceptions instead of returning false on errors, improving error handling ergonomics and code safety. It specifically targets PHP developers who want exception-based error handling without manual false-checking boilerplate, and includes PHPStan integration to enforce safe-function usage across codebases. Not for projects requiring maximum performance or those already using strict type systems that eliminate these patterns.
Inferred from signals mentioned in the README (tests, CI, type safety) — not a review of the actual code.
AI's overall editorial judgment — not an average of the bars above, can weigh other factors too.
Exception-throwing wrapper for PHP core functions addresses error-handling gap in legacy language design
Safe-PHP rewrites PHP's core functions to throw exceptions instead of returning false on error, addressing a fundamental design inconsistency in PHP. It targets teams working in codebases where exception-based error handling is standard practice. The library appears moderately adopted in disciplined PHP shops that use static analysis tooling (PHPStan). Real-world adoption signals are present but not extensively documented; it solves a real pain point but requires deliberate adoption patterns.
Created in September 2018 by TheCodingMachine as a response to PHP's pre-exception era API design. The project emerged as PHP 7+ adoption made exception handling more mainstream, creating friction between legacy false-return functions and modern error patterns. It addresses a specific quirk of PHP's evolutionary history rather than solving a problem in newer languages.
The project gained 2,490 stars over ~7 years with steady but modest growth (0 stars in the last 7 days relative to July 2026). Growth appears plateaued, suggesting the project has reached its natural audience rather than experiencing acceleration. The emphasis on PHPStan integration (circa 2019-2022 period) likely drove adoption among teams already using static analysis. No evidence of viral adoption or recent momentum shifts.
Adoption not explicitly verified through documented case studies or known enterprise users. However, Packagist download metrics are referenced in README badges (suggesting tracking exists but counts not provided in excerpt). Moderate star count (2,490) and 167 forks suggest adoption among at least a committed minority. The emphasis on PHPStan integration suggests real-world pain point recognition, but widespread production usage is not confirmed. Library solves a genuine friction point in PHP codebases, making adoption plausible even if not loudly advertised.
Appears to be a function-wrapping library where ~1000+ core PHP functions are redeclared in a Safe namespace with exception-throwing behavior. Based on README, functions are auto-generated from PHP documentation. The library includes two safe-wrapped classes (DateTime, DateTimeImmutable). PHPStan rule integration allows static detection of unsafe function usage; Rector configuration enables automated migration. Likely organized as a thin adapter layer rather than reimplementation.
README mentions codecov integration and a Tests GitHub Actions workflow badge, suggesting automated testing infrastructure exists. Specific coverage percentage not stated in README. Coverage appears intentional but degree of comprehensiveness not documented.
Last push March 3, 2026 (4 months prior to analysis date) indicates active but not frequent maintenance. Repository has not been abandoned, but update cadence suggests mature, stable project with low churn rather than active feature development. The MIT license and continuous integration setup indicate professional maintenance standards.
ADOPT IF: your PHP codebase is already using PHPStan, you prioritize exception-based error handling consistency, and you want to reduce boilerplate null/false checks on core PHP functions in new code or during refactoring. AVOID IF: you are building new projects in PHP 8+ (native types and strict_types reduce the pain) or you do not use static analysis tooling (adoption requires discipline). MONITOR IF: you are evaluating PHP error-handling strategies long-term; PHP language evolution may reduce the need for this wrapper, or adoption of similar patterns in the language itself could obsolete the library.
Independent dimensions
Mainstream potential
3/10
Technical importance
6/10
Adoption evidence
5/10
- Requires deliberate opt-in per file (explicit use statements); easy to forget and bypass in large codebases without discipline or tooling enforcement
- Adds ~700µs per request according to README; acceptable for most applications but could matter in performance-critical sections
- Maintenance burden: library must track PHP core function changes and API documentation updates; if maintenance lapses, library could become stale
- Language evolution risk: if PHP 8+ or PHP 9 add native exception-throwing variants or improve type system sufficiently, library may become less relevant for new code
- Integration friction: requires buy-in on PHPStan (or Psalm equivalent) as a workflow requirement; teams without static analysis tooling may not realize the benefit
Library likely remains stable and useful but will not experience significant growth. May eventually be superseded by native PHP language improvements (typed exceptions, stricter defaults in newer PHP versions). Serves as a valuable interim solution for managing legacy API quirks in PHP 7.x+ codebases, especially those adopting static analysis. Real value is likely highest in mid-sized teams transitioning from procedural to exception-based error handling.
Newsletter
Get analyses like this every Monday
Free weekly digest of the most interesting open-source discoveries.
Languages
Information
- Language
- PHP
- License
- MIT
- Last updated
- 15h ago
- Created
- 96mo ago
- Analyzed with
- anthropic/claude-haiku-4-5
Stars over time
Contributors over time
Top 100 contributors only — repos with more will plateau at 100.
Open issues
Missing Function: ldap_search
Broken Function: Return type of stream_isatty is incorrect
Missing Function: apcu_store
Removed DocBlock descriptions is a DX regression
Package is too large
Top contributors
Recent releases
Similar repos
php-standard-library/php-standard-library
PSL is a comprehensive standard library for PHP 8.4+ that provides type-safe...
schmittjoh/php-option
This PHP library implements the Option type, a functional programming pattern...
| Repository | Stars | Week Δ | Language | Score | Updated |
|---|---|---|---|---|---|
|
|
2.5k | +1 | PHP | 8/10 | 15h ago |
|
|
1.6k | — | PHP | 8/10 | 2w ago |
|
|
2.7k | — | PHP | 8/10 | 6mo ago |
|
|
14k | — | PHP | 9/10 | 2d ago |
|
|
9.3k | — | CSS | 7/10 | 2mo ago |
Similar adoption level (2,677 stars) but takes opposite approach: uses Option/Maybe monad pattern rather than exceptions. Targets functional programming paradigm; Safe targets imperative exception-handling paradigm. Different philosophical choices for same problem domain.
Broader scope (general standard library improvements, 1,554 stars) vs. Safe's narrow focus (error-handling consistency). Safe is more specialized; PSL is more general. Safe's tighter scope likely aids maintainability.
Modern PHP versions reduce some error-handling ambiguity through type system improvements. Safe addresses orthogonal problem (false returns in untyped functions), but language evolution may reduce long-term relevance for greenfield projects.
Psalm (alternative to PHPStan) offers similar static analysis capabilities. Safe's PHPStan rule is specific; Psalm users may need different tooling or may handle unsafe functions through type annotations differently.