Google News
logo
FuelPHP - Interview Questions
What about Application logic errors in FuelPHP?
Error 404 : The 404 route is set in app/config/routes.php and must point to the controller/method that handles the 404 pages. Read more about it in the routing section.
 
Throwing a 404 : There may be times when one needs to throw a 404 error, such as when handling the routing yourself. This is simply done by throwing a HttpNotFoundException. Fuel will exit for you once it has run the 404 page.
throw new HttpNotFoundException;

 

If you don't want this behaviour, change your index.php file to read
// Generate the request, execute it and send the output.
try
{
    $response = Request::forge()->execute()->response();
}
catch (HttpNotFoundException $e)
{
    $route = array_key_exists('_404_', Router::$routes) ? Router::$routes['_404_']->translation : Config::get('routes._404_');
    if ($route)
    {
        // add 'false' to the forge request do disable the routing engine
        $response = Request::forge($route, false)->execute()->response();
    }
    else
    {
        throw $e;
    }
}
404 handling : When a request is made and after the router looked for possible matches and there is no match, the 404 handling comes into play. By default the _404_ route points to welcome/404, let's take a look at that method:
// Inside Controller_Welcome

/**
 * The 404 action for the application.
 *
 * @access  public
 * @return  void
 */
public function action_404()
{
    $messages = array('Aw, crap!', 'Bloody Hell!', 'Uh Oh!', 'Nope, not here.', 'Huh?');
    $data['title'] = $messages[array_rand($messages)];

    // Set a HTTP 404 output header
    return Response::forge(Presenter::forge('welcome/404', $data), 404);
}
Here you can see what's going on inside the 404 handler. As you can see it's a normal controller action. What's nice about this is that it allows you to show whatever content you like on the page. You can load your own views with data fetched from a database.
 
Catch all : Because Fuel doesn't set the 404 response status, you can use it as a catch all function. You might have have a page model that can fetch the page from a database by uri. Here is an example to illustrate the possibilities:
// Inside your 404 controller

public function action_my404()
{
    $original_uri = \Input::uri();
    $result = \DB::select()->from('pages')->where('uri', $original_uri)->execute();
    if(count($result) === 1)
    {
        // display that page in whatever way you like
    }
    else
    {
        // display your general 404 page
        $messages = array('Aw, crap!', 'Bloody Hell!', 'Uh Oh!', 'Nope, not here.', 'Huh?');
        $data['title'] = $messages[array_rand($messages)];
        return Response::forge(View::forge('welcome/404', $data), 404);
    }
}
Throwing a 500 : There may be moments where your applications simply need to stop and show an error to indicate that something has gone wrong on the server. Normally this is a 500 Internal Server Error. This exception can be caught in the front controller by defining a _500_ route. It allows you to show a proper error message, do additional error logging, or send a notification to an administrator to get the issue fixed.
 
Similar to throwing a 404, one can throw a 500 error.
throw new HttpServerErrorException;
Throwing a 403 : If you want centralized handling of access violations, you can choose to signal an access violation by throwing an HttpNoAccessException. This exception can be caught in the front controller by defining a _403_ route. The handler could for example store the current URI, ask for a login, and if a success, return to the stored URI so the user can return to where the violation occured.
 
Similar to throwing a 404, one can throw a 403 error.
throw new HttpNoAccessException;
Advertisement