thecodingmachine

thecodingmachine/safe

PHP MIT Dev Tools

All PHP functions, rewritten to throw exceptions instead of returning false

2.5k stars
168 forks
active
GitHub +1 / week

2.5k

Stars

168

Forks

34

Open issues

30

Contributors

v3.4.0 15 Feb 2026

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.

Dev Tools Library Discovery value: 4/10
Documentation 9/10
Activity 9/10
Community 8/10
Code quality 8/10

Inferred from signals mentioned in the README (tests, CI, type safety) — not a review of the actual code.

Overall score 8/10

AI's overall editorial judgment — not an average of the bars above, can weigh other factors too.

error-handling php-functions exception-driven static-analysis developer-productivity
Actively maintained Well documented MIT licensed Niche/specialized use case Beginner friendly Production ready
Deep Analysis · Based on README and public signals
5d ago

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.

Origin

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.

Growth

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.

In production

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.

Code analysis
Architecture

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.

Tests

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.

Maintenance

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.

Honest verdict

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

Risks
  • 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
Prediction

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.

0 found this helpful

Newsletter

Get analyses like this every Monday

Free weekly digest of the most interesting open-source discoveries.

Languages

PHP
99.6%
Dockerfile
0.3%
Shell
0.1%

Information

Language
PHP
License
MIT
Last updated
15h ago
Created
96mo ago
Analyzed with
anthropic/claude-haiku-4-5

Stars over time

Loading…

Contributors over time

Top 100 contributors only — repos with more will plateau at 100.

Loading…

Similar repos

php-standard-library

php-standard-library/php-standard-library

PSL is a comprehensive standard library for PHP 8.4+ that provides type-safe...

1.6k PHP Dev Tools
schmittjoh

schmittjoh/php-option

This PHP library implements the Option type, a functional programming pattern...

2.7k PHP Dev Tools
phpstan

phpstan/phpstan

PHPStan is a static analysis tool for PHP that identifies bugs and type errors...

14k PHP Dev Tools
codeguy

codeguy/php-the-right-way

PHP: The Right Way is a comprehensive, community-maintained reference guide for...

9.3k CSS Education
vs. alternatives
schmittjoh/php-option

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.

php-standard-library/php-standard-library

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.

Native PHP 8+ typed properties and union types

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.

Typed arrays / psalm integration

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.