Framework Skeleton: Setting STDERR Reporters

Error reporters are STDERR MVC API components created to log errors latter handles into one or more storage mediums.

How do they work?

Since API is completely atomic, it makes no assumption of logging solution used. Instead, it provides a platform to which ANY logger can be plugged into by implementing Lucinda\MVC\STDERR\ErrorReporter interface. Lucinda Framework uses that plug to bind Lucinda\MVC\STDERR\ErrorReporter to Lucinda\Logging\Logger instances via LogReporter class all loggers will need to extend, thus making a bridge between STDERR MVC API and Logging API.

How are they located?

In order to be found by API, each logger will need to present itself as a <reporter> tag in stderr.xml whose value of "class" attribute matches logger class name. Then logger needs to extend LogReporter, configure itself in constructor based on tag settings received as argument and exist as same file name in folder set by <reporters> @ <application> tag.

1. STDERR MVC allows you to plug multiple reporters: the more <reporter> tags you have for development environement, the more destinations exception will be logged into at the same time.
2. Reporting is provided in best effort mode (thus not guaranteed): if an error has occurred during logging process, associated exception is silently caught and execution continues.
3. Having loggers isn't mandatory, but highly recommended!

What does framework already come with?

Framework skeleton comes with two error reporters preinstalled but users can add their own:

Both reporters preinstalled use same message format algorithm defined by LogFormatter class. Required attribute "format" of their respective tag will thus use contain a concatenation of recognized patterns. Let's say we want to log in a file called errors.log by "(date) (file) (line) (exception) (message)". Then tag will be:

<reporter class="FileReporter" path="errors" format="%d %f %l %e %m"/>

So when someone in PHP throws a uncaught EXCEPTION with MESSAGE in file FILE at line LINE, then following line is appended automatically to errors.log:



This class is a wrapper of FileLogger, inheriting all latter functionalities. As such, it can:

This is the preferred method, since you are in control of the whole process, unless your site lies in a distributed system.


This class is a wrapper of SysLogger, inheriting all latter functionalities. As such, it can:

It must be remembered that syslog automatically includes patterns in message (date, application name). Please ask sysadmin or manually check how messages are formatted, to know what's left to be done from your part!

When are exceptions reported?

Decision of whether or not to log or how to report an exception is based on development environment (for example on local environment we may not want to log errors at all) and exception itself. Each exception STDERR handles corresponds to an <exception> route in stderr.xml or to default <exceptions> route (if former is absent). For each route there is an "error_type" attribute whose value can be: