Download the PHP package voku/error-handler-lib without Composer
On this page you can find all versions of the php package voku/error-handler-lib. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download voku/error-handler-lib
More information about voku/error-handler-lib
Files in voku/error-handler-lib
Package error-handler-lib
Short Description Portable PHP error-handler library with integration hooks for application-specific logging and rendering.
License MIT
Homepage https://github.com/voku/error-handler-lib
FAQ
Example:
In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
- Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
- To use Composer is sometimes complicated. Especially for beginners.
- Composer needs much resources. Sometimes they are not available on a simple webspace.
- If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
- Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Informations about the package error-handler-lib
ErrorHandlerLib
A small, portable PHP error-handler library with application integration hooks for logging, rendering, filtering, and object descriptions.
The package is designed to be installed through Composer and then adapted by the host application through ErrorHandlerIntegrationInterface.
Installation
Usage
For application-specific behavior, provide an integration:
The error report hands you a prompt
Every rendered error report ends with a copy&paste-ready prompt for a coding agent, built from the diagnostic the handler already has:
It is deterministic: no timestamps, no request identifiers, no environment probing, no model call. The same diagnostic always renders the same bytes, so repeated occurrences deduplicate.
The visibility line is the part worth having. An agent that is told a warning was hidden by @
does not "fix" it by hiding it again, and the prompt says so explicitly.
Two boundaries it respects:
- Call arguments are never rendered. They are the values most likely to hold credentials, so the
call path carries navigation only. The whole prompt still passes through
sanitizeErrorDetails()exactly like the error details do. - Logs stay machine-shaped. The prompt is appended to what a human is about to read, not to
error_log(), and only when the integration echoes output.
Call debugPrompt() directly to put the same text somewhere else — a debug-bar panel, an issue
template, a chat message:
PHP suppression vs. application filtering
The handler is registered for E_ALL and does not simply obey error_reporting(). That is
deliberate: a warning hidden by @ is often the most valuable thing on the screen.
Please do not write new @ code because of this. The point is that existing @ in your own code,
in vendor code, or in a tool you are running does not quietly cost you an afternoon of debugging.
Three separate decisions are evaluated in this order, and only the first one is PHP's:
| # | Question | Owner |
|---|---|---|
| 1 | Is this diagnostic critical/fatal? | the library — critical diagnostics skip steps 2 and 3 entirely |
| 2 | PHP excluded this diagnostic; is it still interesting? | ErrorHandlerIntegrationInterface::suppressedDiagnosticPolicy() |
| 3 | Is this specific diagnostic intentionally ignorable? | ErrorHandlerSkipDeciderInterface::shouldSkip() |
Only after all three does anything observable happen (debug bar, logging, rendering).
Choosing a suppressed-diagnostic policy
"Suppressed" means the error_reporting() state active while the diagnostic was raised does not
contain its type — both @expr and an explicit error_reporting() mask.
| Case | Behavior | Typical host |
|---|---|---|
Observe (default) |
suppressed diagnostics are handled like reported ones | development, tests, CI |
LogOnly |
logged and recorded, never rendered into the output | production, or a narrow policy for an external tool run |
Ignore |
not processed at all; PHP's normal suppression semantics apply | production that wants PHP defaults back |
Note that PHPUnit narrows error_reporting() to a fatal-only mask while a test runs, so under
PHPUnit almost every diagnostic looks PHP-suppressed. Observe is what keeps the handler useful
there.
What SkipDecider guarantees
A skipped diagnostic produces no observable processing side effects: no logging, no debug-bar
entry, no rendering, no counters, no further integration callbacks. handleError() returns true
for it, because the host explicitly claimed the diagnostic.
Ignore returns false instead: the library declines and leaves the diagnostic to PHP.
Guarantees that no policy can weaken
Critical diagnostics, uncaught exceptions, and shutdown-detected fatal errors are handled before
the suppression policy and the skip decider are consulted. Neither can hide them, whatever
error_reporting() says. tests/Fixture/ proves this end to end against the most hostile host
policy the API allows.
