STDERR MVC API: Handling Errors Into Responses

This revolutionary API elegantly and efficiently handles errors/exceptions that may occur in an application into log reports and server responses using a dialect of MVC paradigm.

How does it work?

This API implements a variation of Model-View-Controller pattern tailor made to fits its design requirements. API logic is bootstrapped by a FrontController class. FrontController's job is to handle exceptions (incl. errors) by sending them to reporters (if any) then issue a HTTP response based on contents of user-defined xml file where your application is set up.

In order to be aligned to the principle of doing nothing more than absolutely required, since most page requests made by users won't throw exceptions, this api runs in two steps:

  1. instantiation: FrontController is instanced by application bootstrap file. In its constructor it registers itself as sole handlers of PHP errors (normal or fatal) and uncaught exceptions. From that moment on it will lie in dormant mode as request is handled in normal stderr stream, so it only loads the logic necessary for registration.
  2. handling: when an error or an exception was thrown in stderr stream, handle() method is automatically executed. Only then does API read XML and load all of its dependencies necessary in order to:

Instead of implementing handling logic by itself, FrontController delegates to components dedicated to a particular aspect of this process. These components are of two types:

All classes inside API belong to namespace Lucinda\MVC\STDERR! User defined components need not (and should not) use that namespace.

What are the steps taken to issue response to handled exception?

The order in which FrontController performs handling is:

  1. Redirects its own errors to an user-defined ErrorHandler instance received as constructor argument.
  2. Constructs Application object based on xml file.
  3. Constructs Request object based on handled exception.
  4. Uses ReportersLocator to locate then instances and runs user-defined ErrorReporter classes found.
  5. Constructs Response object based on Application and Request information.
  6. If handled exception is associated to a controller, uses ControllerLocator to locate then instances and runs matching user-defined Controller class based on Application, Request and Response objects.
  7. Uses RendererLocator to locate then instances and runs matching user-defined ErrorRenderer class found.
  8. Displays response back to caller by running commit() method @ Response object

How can I install and use it?

To learn how to install and use this API, follow this step-by-step guide!