Question

I’m trying to develop a personal MVC framework for learning purposes. But every time I’m stuck in this problem: errors.

I feel like I’m handling them very bad. Currently I have an exception system (everything is converted to exception, even PHP triggered errors) that is catch in a try{} block that contains every line of code of the framework and the user application.

I’m treating errors such as “controller not found” or “action not found” like any other, for example “unable to connect to the database”. But I feel like the latter is somehow more an “exception” rather than a pretty common “controller not found (404)”.

Also currently I’m using an error handling that pretty much copy the way MVC works in my framework, in the sense that when an error occurs I load a specific action and load a specific view file for each type of error. I’m not using the MVC (by MVC I mean all the mechanism that load a controller, run an action, load a model and views for the user application) of my framework because an error in the MVC could cause an error to be triggered, which would try to manage it with the MVC which would trigger the same error again and then the MVC to be loaded again and so on in an infinite loop.

How should I handle every error of my framework? What are the best practice right now?

Answer 1

The execution of controller IMHO can generate two exceptions:

• not found: when controller or method is missing
• permission denied: when ACL blocked access

To handle this, i would just go with something like following code. And you can use multiple catch block.

try
{
    $controller->$command($request, $response);
}
catch(AccessDeniedException $e)
{
    $controller = new ErrorController;
    $controller->accessDenied($request, $response);
}
catch(NotFoundException $e)
{
    $controller = new ErrorController;
    $controller->notFound($request, $response);
}

You can let AccessDeniedException to bubble up from Model Layer too, but usually it is a bad practice. Exception should be handles within same level of abstraction, where it was thrown, or, in case of critical exceptions (when object itself is unable to deal with it), the exceptions might penetrate ONE abstraction boundary. And exceptions should NOT leave the Model Layer, instead they should create error state in the layer, and be processed in your current View instance.

The point is this: instead of magical handler for all errors, you should handle errors close to the place where it originated.