Google News
logo
FuelPHP Interview Questions
FuelPHP is a simple, flexible, community driven PHP 5 web framework. It was born out of the frustrations people have with the current available frameworks and developed with support from a community of developers. FuelPHP is extremely portable, works on almost any server and prides itself on clean syntax.

The framework was started in late 2010 by Dan Horrigan then shortly after the team grew to include Phil Sturgeon, Jelmer Schreuder and Harro Verton.
In order to install FuelPHP 1.8, your server need to meet beneath requirements
 
PHP Version >= five.3.3
Mbstring PHP extension set up and enabled
Mcrypt PHP extension hooked up and enabled
File info PHP extension mounted and enabled

PHPUnit version 3.7 or more is required if you want to run unit assessments.
A class is just a normal PHP class. It doesn't need to extend anything or follow any conventions other than the naming convention which is the same as all other classes in Fuel.
class Session
That will be loaded from app/classes/session.php.
 
Loading Classes : 
Unlike some other frameworks classes do not need to be loaded manually. They will be auto-loaded when you refer to them in your code (Controllers, Models, etc).
 
Classes in a sub-directory : 
Just like Controllers, classes must be lower-case with first-letter upper case, while underscores will put the class into a sub-directory.
Class Session_Driver
That will be loaded from app/classes/session/driver.php
 
Classes and Namespaces :
To determine which PHP file to load, FuelPHP's autoloader will treat namespaces and class names with underscores exactly the same. This means that for classes in sub-directories, you can mix-and-match namespaces and underscores to suit your needs.
 
Take for example a class in the file app/classes/core/system/messages.php. The class in this file can be defined as:
// global namespace, fully underscored class name
class Core_System_Messages {}

// combine a namespace and underscores
namespace Core;
class System_Messages {}

// or fully namespaced
namespace Core\System;
class Messages {}
The first method is the one most commonly used and easiest to understand. The namespaced versions are particularly handy if you combine them with the Use statement in the classes that use the defined class.

Initializing your class :
It is possible to have Fuel's autoloader perform certain automated tasks once a class is loaded, sort of like what __construct() does for instances of a class. You do this by adding a public static _init() method to the class.
class Example {
    public static function _init()
    {
        // this is called upon loading the class
    }
}
If a loaded class has its own _init() method and a parent must be loaded alongside it, that parent's init method isn't called unless you call it using parent::_init();
Be sure to know what you are doing, extended core methods under the same name will be used by the core as well as by your application and this may result in unexpected behavior.
 
* Extending but not replacing the core class
* Extending & replacing core classes
* Extending the Core from packages
* Extension limitations

Extending but not replacing the core class : These are the easiest and will work like any other class you create; just make them extend the core class in the global namespace :
class MyConfig extends Config {}

Extending & replacing core classes : 
If you want your core extension to be used by the core as well as by your own application you need to extend it under the same name but take it from the "Fuel\Core" namespace. Below is an example for the Lang class which you create in "fuel/app/classes/lang.php":
class Lang extends Fuel\Core\Lang {}
 
Extending the Core from packages :  By adding your package as a core namespace the autoloader will attempt to load any class from your package before it attempts it from the core. You must register these classes with the Autoloader though in order for them to be detected (filesystem autoloader doesn't support aliasing to global). Below is an example for extending the View class.
Autoloader::add_core_namespace('Example');

Autoloader::add_classes(array(
    'Example\\View'  => __DIR__.'/classes/view.php',
));
 
Extension limitations :  All classes can be extended from app. Most classes can be extended from packages but there are a few exceptions:
 
* Fuel
* Config
* Config_Php
* Config_File
* Config_Interface
* Finder
* Arr
* Input
* Security
* Event
* Event_Instance
* And any class you use in your main app/config/config.php

If you have activated the profiler in your configuration, you can not extend these classes from packages too :
 
* Cookie
* Session
* Session_Cookie (or another session driver class, depending on your session configuration)
* Session_Driver
* Date
* Profiler

You can work around some of these limitations by manually load your package in the app/bootstrap.php file, by adding Package::load('mypackagename'); just before the Fuel::init() call. If you do, your package can only not extend:
 
* Fuel
* Config
* Package
* Arr
* Finder
The Autoloader class is a special case, you can only extend it once as Autoloader and have it used. After extending it you have to require it manually in the app/bootstrap.php file after the original Fuel\Core\Autoloader, don't forget to remove the line that aliases the core class to global.
Fuel has four constants in the global namespace to direct you to important directories. Fuel uses them internally to locate classes and other files. These constants are set in public/index.php.
 
Note: When you move any of fuel's prime folders (app, core, public, packages) be sure to update your index.php to direct fuel to the right paths.
 
KEYS :

* APPPATH :
Path to the application directory (/path/to/fuel/app). This is where your application directories and code reside.

* COREPATH : Path to the core directory (/path/to/fuel/core). This is where all the Fuel classes live.

* DOCROOT : Path to the location where the 'startup script' is. For your web application, path to the public directory (/path/to/public). This is where index.php resides. Everything accessible to user lives and is accessible via the browser. For oil command, path to where oil command resides.

* PKGPATH : Path to the packages directory (/path/to/fuel/packages). This is where your packages are installed (when installed through oil).

* VENDORPATH : Path to the composer root directory (/path/to/fuel/vendor). This is where your composer installs the libraries downloaded from packagist.org.
MVC is an approach to separating your code depending on what role it plays in your application. In the application flow it starts with a controller that is loaded. That Controller executes a method which retrieves data using Models. Once it is done the controller decides what View to load, which contains the output your visitors get to see.
 
Controllers : Controller classes are located in APPPATH/classes/controller
 
Fuel's routing decides based on the requested URL what controller to load and what method to call upon it. This is where your application starts working. The Controller decides what actions to take, what to do with any user input, what data gets manipulated and which View is shown to the user. The Controller does none of these things itself however; it calls upon Models and Classes to do the work.
 
Models : Model classes are located in APPPATH/classes/model
 
Whenever data needs to be retrieved, manipulated or deleted this should always be done by a model. A Model is a representation of some kind of data and has the methods to change them. For example: you never put SQL queries in a Controller, those are put in the Model and the Controller will call upon the Model to execute the queries. This way if your database changes you won't need to change all your Controllers but just the Model that acts upon it.
 
Views : Views are located in APPPATH/views
 
Views contain your HTML, which should never be found in your Controllers or any other class that is not specifically meant to create output. By separating your layout from your logic you ensure that when you decide to change your layout you only have to change the views and won't have to care about the Controllers.
Views should thus contain little more than echo and foreach usage of PHP.
 
Presenters : Presenter classes are located in APPPATH/classes/presenter
 
Once your application gets more complex you'll discover that it gets hard to decide if a piece of logic really belongs in the Controller, what if it is very specifically about the View and has little to do with your application logic? This is where Presenters come in; they are the glue between your controllers and your views.
FuelPHP, as a PHP 5.3+ framework, relies heavily on namespacing to separate the different components of the framework and of your application, to make the code as portable as possible, and to prevent any collisons in class names when you're moving bits of your application around.
 
By default, the exception to this is your main application code, which resides in APPPATH/classes. All main application classes are defined in the global namespace (they do not have a namespace set), and use the cascading file system to create unique classnames.
 
While this makes it easier for the novice to start using the FuelPHP framework, it will create more complex class names, and it will make those classes less portable or interchangeable.
As mentioned in the introduction, by default controllers are created in the APPPATH/classes/controller folder, and are prefixed with Controller_. This prefix is defined in your APPPATH/config/config.php configuration file (and if not this is the default), but can be changed if you want to namespace your controllers, or if you want to move them to a different folder structure.
 
Let's move the example given above to the Controller namespace. You tell FuelPHP that you've done this by setting the config setting controller_prefix from 'Controller_' to 'Controller\\' in your app's config.php file.
namespace Controller;

class Example extends \Controller
{
    public function action_index()
    {
        // some code here
    }
}
Once you have enabled namespacing for your controllers, ALL your controller classes need to be namespaced! This means a controller in a module called Mymodule will look like this :
namespace Mymodule\Controller;

class Example extends \Controller
{
    public function action_index()
    {
        // some code here
    }
}
Fuel's routing can range from simple static routes to advanced routes using HTTP verb based routing.
 
Routes are set in fuel/app/config/routes.php.
 
Reserved Routes : 

In Fuel there are 4 reserved routes. They are _root_, _403_, _404_ and _500_.
 
_root_ : The default route when no URI is specified.
_403_ : The route used when the application throws an HttpNoAccessException that isn't caught.
_404_ : The route used when the application throws an HttpNotFoundException that isn't caught.
_500_  : The route used when the application throws an HttpServerErrorException that isn't caught.
return array(
    '_root_'  => 'welcome/index',
    '_404_'   => 'welcome/404',
);
Basic Routing : The route on the left is compared to the request URI. If a match is found, the request is routed to the URI on the right.
 
This allows you to do things like the following:
return array(
    'about'   => 'site/about',
    'contact' => 'contact/form',
    'admin'   => 'admin/login',
);
Slightly Advanced Routing : You can include any regex into your routes. The left side is matched against the requests URI, and the right side is the replacement for the left, so you can use backreferences in the right side from the regex on the left. There are also a few special statements that allow you match anything or just a segment:
 
:any : This matches anything from that point on in the URI, does not match "nothing"
:everything : Like :any, but also matches "nothing"
:segment : This matches only 1 segment in the URI, but that segment can be anything
:num : This matches any numbers
:alpha : This matches any alpha characters, including UTF-8
:alnum : This matches any alphanumeric characters, including UTF-8

Here are some examples. Notice the subtle differences between :any and :everything :
return array(
    'blog/(:any)'       => 'blog/entry/$1', // Routes /blog/entry_name to /blog/entry/entry_name
                                            //   matches /blog/, does not match /blogging and /blog
    'blog(:any)'        => 'blog/entry$1',  // Routes /blog/entry_name to /blog/entry/entry_name
                                            //   matches /blog/ and /blogging, does not match /blog
    'blog(:everything)' => 'blog/entry$1',  // Routes /blog/entry_name to /blog/entry/entry_name
                                            //   matches /blog/, /blogging and /blog
    '(:segment)/about'  => 'site/about/$1', // Routes /en/about to /site/about/en
    '(\d{2})/about'     => 'site/about/$1', // Routes /12/about to /site/about/12
);
You can also have named parameters in your routes. This allows you to give your URI segments names which can then be accessed from within your actions.
 
Example :
return array(
    'blog/:year/:month/:id' => 'blog/entry', // Routes /blog/2010/11/entry_name to /blog/entry
);
In the above example it would catch the following /blog/2010/11/entry_name. It would then route that request to your 'entry' action in your 'blog' controller. There, the named params will be available like this :
$this->param('year');
$this->param('month');
$this->param('id');
You can route your URLs to controllers and actions based on the HTTP verb used to call them. This makes it quick and easy to make RESTful controllers.
 
Example :
return array(
    // Routes GET /blog to /blog/all and POST /blog to /blog/create
    'blog' => array(array('GET', new Route('blog/all')), array('POST', new Route('blog/create'))),
);
You can use named parameters and regexes within your URL just like normal :
return array(
    'blog/(:any)' => array(array('GET', new Route('blog/show/$1'))),
);
You can also specify if this route is supported for only http, or only https, by passing false or true as third parameter :
// route only valid if this is an https request
return array(
    'blog/(:any)' => array(array('GET', new Route('blog/show/$1'), true)),
);
The idea of reversed routing is like this: say you got an admin area and you have a route setup for it. In your views, you would like to that admin area using an HTML anchor that links to for example 'admin/start/overview'. Now you decide to move stuff around and end up moving that specific page to 'admin/overview'. As a result of this now you need to update the links in all your views...
 
When using reverse routing with these name routes you can link an anchor to a named route, so that when the route changes, the links in your views will automatically follow the change
 
Example route :
return array(
    'admin/start/overview' => array('admin/overview', 'name' => 'admin_overview'), // add a named route for the admin/overview page
);
Example anchor :
// produces <a href="http://your_base_url/admin/start/overview">Overview</a>
echo Html::anchor(Router::get('admin_overview'), 'Overview');
A route does not have to resolve to a controller method. FuelPHP also supports inline routes, which are defined as a Closure that replaces the controller method. Like controller methods, inline routes MUST return a Response object, either by forging one manually, or as the result of executing a forged Request.
 
Example route :
return array(
    'secret/mystuff' => function () {
        // this route only works in development
        if (\Fuel::$env == \Fuel::DEVELOPMENT)
        {
            return \Request::forge('secret/mystuff/keepout', false)->execute();
        }
        else
        {
            throw new HttpNotFoundException('This page is only accessable in development.');
        }
};
Fuel takes security very serious, and as a result, has implemented the following measures to ensure the safety of your web applications :
 
* Output encoding
* CSRF protection
* XSS filtering
* Input filtering
* SQL injection

By default, Fuel doesn't filter POST and GET variables on input, and encodes everything on output. Fuel also encodes the URI to prevent nasty surprises when using URI segments, and escapes everything going into the database.
By default, Fuel favors output encoding to input filtering. The reason behind this is twofold. No matter where your data originates, and whether or not it is filtered, output encoding will make it harmless when it is send to the client. It also means all input is stored in raw and unaltered form, so that no matter what happens, you will always have access to the original data.
 
Since output encoding can only happen on strings, you have to pay attention to objects you want to pass to your views. Either make sure your object contains a __toString() method on which the encoding can take place, add your object class to the class whitelist in the security configuration (don't forget the namespace!), or pass it to the view with the $encode flag set to false. You can also use the auto_encode method to temporary disable automatic output encoding on a per-view basis.
Cross-site request forgery, also known as a one-click attack or session riding and abbreviated as CSRF, is a type of malicious exploit of a website whereby unauthorized commands are transmitted from a user that the website trusts. Unlike cross-site scripting (XSS), which exploits the trust a user has for a particular site, CSRF exploits the trust that a site has in a user's browser. The attack works by including a link or script in a page that accesses a site to which the user is known (or is supposed) to have been authenticated.

CSRF protection can be configured through the security section in the applications config/config.php file.
 
To enable CRSF protection, start by adding the token to your form:
// in plain HTML
<input type="hidden" name="<?php echo \Config::get('security.csrf_token_key');?>" value="<?php echo \Security::fetch_token();?>" />

// using the Form class
echo \Form::csrf();

// using a form instance, will also add a validation rule to forms fieldset
$form = \Form::forge();
$form->add_csrf();
To manually check if the form has been submitted by the client that requested the form :
// check if a form was submitted
if ($_POST)
{
    // check for a valid CSRF token
    if ( ! \Security::check_token())
    {
        // CSRF attack or expired CSRF token
    }
    else
    {
        // token is valid, you can process the form input
    }
}
Fuel provides XSS filtering using the HTMLawed library, a very fast and highly configurable library. By default it runs in safe and balanced mode.
 
Safe refers to HTML that is restricted to reduce the vulnerability for scripting attacks (such as XSS) based on HTML code which otherwise may still be legal and compliant with the HTML standard specs. When elements such as script and object, and attributes such as onmouseover and style are allowed in the input text, an input writer can introduce malevolent HTML code.
 
In balanced mode, HTMLawed checks and corrects the input to have properly balanced tags and legal element content (i.e., any element nesting should be valid, and plain text may be present only in the content of elements that allow them).
Although not enabled by default, you can configure Fuel to filter all input ($_GET, $_POST and $_COOKIE) on every page request. To do so, configure the functions or methods to be used to filter them in the application's config/config.php file.
/**
 * Security settings
 */
'security' => array(
    'input_filter' => array(),
)
Anything that is callable in PHP and accepts a single value as parameter can be used for filtering purposes. This includes PHP functions like 'htmlentities', static class methods like '\\Security::xss_clean' or even object methods which are defined as array($object, 'method'). If you use an object method, make sure the object is available before Fuel is initialized, as input filtering happens very early in the request process.
A module is a group of independent MVC elements. The use of modules allows for re-usability and encapsulation of your code. A module typically resides within an application sub-directory named modules. It is suggested to take advantage of modules whenever you're working on a large project, of which you believe the code-base will be more than just a few lines of code. It will help you to keep things neatly in order.
 
A module can operate independently, like for example a blog module or an album module. You can route directly to the module controllers, without having to access any global code. Modules can also be used in a true HMVC context, where controllers call other controllers, which will produce (a part of) the result needed to generate the result of the page request.
To be able to use modules, you will have to tell Fuel where your modules are stored. By default, this is in the modules folder of your application. You use the 'modules_path' setting in your applications config.php file to define your module path. You can also define multiple paths. If you do, they will be searched in the sequence you have defined them.
/**
 * To enable you to split up your application into modules which can be
 * routed by the first uri segment you have to define their basepaths
 * here.
 */
'module_paths' => array(
    APPPATH.'modules'.DS,		// path to application modules
    APPPATH.'..'.DS.'globalmods'.DS	// path to our global modules
),
One of the problems often encountered when working with independently developed code are class name collisions. For example, a lot of modules come with an admin controller. To avoid collisions, in Fuel every module lives in its own PHP namespace, which must be named identical to the folder name of the module.
<?php
/**
 * Module controller in the Mymodule module
 */

namespace Mymodule;

class Controller_Widget
{

    // put your controller code here, just like for an application controller
}
Besides using modules as a way of separating logically independent parts of your application, you can also use module controllers in an HMVC context, where one of your application's controllers calls one of more module controllers to create the final result of the URI requested.
When it comes to organizing, reuse and share your code, packages are a great way to allow you to do this. They can contain all sorts of code like models, third-party libraries, configs and so on. Packages also allow you to extend the core without messing up your app/classes directory. To clarify what packages are, here are the "is" and "is not" on packages.
 
Packages : 
* are a great way to organize your code,
* supply a place to keep third party libraries,
* allow you to extend other packages without messing with someone's code,
* a place to extend fuel without messing with core files.
But.
        * packages do not map to the URL,
        * and are not approachable through HMVC requests

Creating packages : To help people understand what you are doing it's best to structure your package like so:
/packages
    /package
        /bootstrap.php
        /classes
            /your.php
            /classes.php
            /here.php
        /config
            /packageconfig.php
        /and_so_on
Every package is expected to have a bootstrap.php located at the base of the package. Use the bootstrap to add the package namespace (to global if you wish). And add the classes for better perfomance.
// Add namespace, necessary if you want the autoloader to be able to find classes
Autoloader::add_namespace('Mypackage', __DIR__.'/classes/');

// Add as core namespace
Autoloader::add_core_namespace('Mypackage');

// Add as core namespace (classes are aliased to global, thus useable without namespace prefix)
// Set the second argument to true to prefix and be able to overwrite core classes
Autoloader::add_core_namespace('Mypackage', true);

// And add the classes, this is useful for:
// - optimization: no path searching is necessary
// - it's required to be able to use as a core namespace
// - if you want to break the autoloader's path search rules
Autoloader::add_classes(array(
    'Mypackage\\Classname' => __DIR__.'/classes/classname.php',
    'Mypackage\\Anotherclass' => __DIR__.'/classes/anotherclass.php',
));
HMVC requests are a great way to separate logic and re-use controller logic in multiple places. One common use of this is when you use a theme or template engine to generate your pages, where every page is divided into sections, and sections are populated by widgets. By using modules to produce the widget output, you can create a highly modular application with easy to re-use components.
 
You call a module controller method using the Request class :
// fetch the output of a controller
$widget = Request::forge('mycontroller/mymethod/parms')->execute();
echo $widget;

// or fetch the output of a module
$widget = Request::forge('mymodule/mycontroller/mymethod/parms', false)->execute();
echo $widget;

// and if you need to pass in some data
$widget = Request::forge('mymodule/mycontroller/mymethod/parms', false)->execute(array('tree'=>'apple'));
echo $widget;
If you want to access other Requests, you can traverse them using two methods : $request->parent() and $request->children(). The parent is the Request during which the current Request was created (null for the main Request). The children are all the Requests created during the current Request.
Migrations are a convenient way for you to alter your database in a structured and organized manner. You could edit fragments of SQL by hand but you would then be responsible for telling other developers that they need to go and run them. You’d also have to keep track of which changes need to be run against the production machines next time you deploy.
 
The database table `migration` tracks which migrations have already been run so all you have to do is update your application files and call Migrate::current() to work out which migrations should be run. The current version is found in core/config/migration.php so like any other config file you should copy this to app/config to make changes.

Key Type Default Description
folder string
'migrations/'
The folder in which migration files will be found.
connection string
null
Configuration name of a database connection to use to write migrations.
table string
'migration'
The database table used to store migration data.
flush_cache boolean
false
If true, all cached data will be erased after all migrations have run, via a call to Cache::delete_all().
Create a file in the app/migrations folder. The prefix should be an incremental count starting at 001, do not skip numbers and do not have two numbers that match. The first would be something like app/migrations/001_example.php.
namespace Fuel\Migrations;

class Example
{

    function up()
    {
        \DBUtil::create_table('posts', array(
            'id' => array('type' => 'int', 'constraint' => 5),
            'title' => array('type' => 'varchar', 'constraint' => 100),
            'body' => array('type' => 'text'),
        ), array('id'));
    }

    function down()
    {
       \DBUtil::drop_table('posts');
    }
}
A migration can be run in two ways :
 
* Migrate class
* Oil Refine Command

The oil command there uses the Refine command to call the migrate task.
$ php oil refine migrate
$ php oil refine migrate:current
$ php oil refine migrate:up
$ php oil refine migrate:down
$ php oil refine migrate --version=10
Migrations are supported for modules and packages too. You can specify on the oil commandline if you want to migrate all, or only specific modules and/or packages. If you do, you can use '--default' to indicate you want to include app migrations.
$ php oil refine migrate -all
$ php oil refine migrate --modules=module1,module2 --packages=package1
$ php oil refine migrate:up --packages=package1
$ php oil refine migrate:down --modules=module1,module2 --default
$ php oil refine migrate --version=10
You can abort the migration process by having your up() or down() method return false. This can be useful if your migration has external dependencies, for example the existence of a table created in a different migration.
Optionally, a migration class can contain before() and/or after() methods, that can be used for prepping, validation or cleanup functionality. If you have generic functionality, you could create a migration base class for your migrations containing these methods, so you don't have to duplicate code in every migration.
 
Like with the up() method, the before() and after() methods can return false to signal a failure. This can be useful if your migration has generic external dependencies, or perhaps additional validation steps. When it does, the migration will be skipped, and ultimately aborted if a retry fails too. In the case of the after() method returning false, the migration will be reverted by calling the reverse migration method (i.e. calling down() when on an up() migration, and vice-versa).
Tasks are classes that can be run through the command line or set up as a cron job. They are generally used for background processes, timed tasks and maintenance tasks. Tasks can calls models and other classes just like controllers.
 
Creating a task : In Fuel Tasks are put in the fuel/app/tasks directory. Below is an example of the task "example" :
namespace Fuel\Tasks;

class Example
{

    public function run($message = 'Hello!')
    {
        echo $message;
    }
}
That will be called via the refine utility within oil :
$ php oil refine example "Good morning"​
When just the name of the task is used in the command, the method "run()" is referenced.
 
Splitting tasks into more methods : You can add more methods to your task class to break a group of tasks down into more specific tasks which can be called separately.
public function current_date()
{
    echo date('Y-m-d');
}
We can then call this method using :
$ php oil refine example:current_date
Unit Tests are automated tests written to make sure a unit of code (typically a function or method) is doing what it was designed to do. These tests also help developers to be sure any changes they make to a system do not break anything that is already working. Unit tests are also the key driving force behind the discipline of Test Driven Development (TDD).
 
FuelPHP's included command-line utility Oil is already configured to run your unit tests. You can run all the tests in your FuelPHP project from the command line using the Oil command line utility:
$ php oil test

Tests Running...This may take a few moments.
PHPUnit 3.6.10 by Sebastian Bergmann.

Configuration read from /home/user/sites/example/fuel/core/phpunit.xml

...............................................................  63 / 251 ( 25%)
............................................................... 126 / 251 ( 50%)
............................................................... 189 / 251 ( 75%)
..............................................................

Time: 6 seconds, Memory: 22.25Mb

OK (251 tests, 206 assertions)
In FuelPHP, tests are located in the fuel/app/tests directory and its subdirectories. If this directory does not exist, go ahead and create it. By convention, test files are placed in the same subpath of fuel/app/tests as the tested class is of fuel/app/classes, so a test for the class at fuel/app/classes/model/login.php would be in the file fuel/app/tests/model/login.php.
 
Tests are classes that extend the TestCase class. TestCase is FuelPHP's extension of PHPUnit's PHPUnit_Framework_TestCase class, so you'll be able to use all the usual PHPUnit assertions and methods in your test. By convention, test classes are named after the class they test, prefixed with Test_, so a test for the Model_Login class would be named Test_Model_Login.
class Test_Model_Login extends TestCase
{
    public function test_foo()
    {
    }
}
As you all (should) know error handling is a very important part in the development process. Not only does it show the user that the page he/she/it requested is not available, it's also a way to inform machines (browsers and such) about what’s going on by providing a HTTP error status.
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;
The profiler provides profiling and debugging related information without having to add a lot of programmatic overhead to the code. You only need to toggle one config setting to true and you have access to an automated tool to help create a faster and more consistent review experience. Since anyone can use it, the profiler also gives you an idea of where the code stands before the review.
 
The profiler provides you with a tabbed interface, in which you can find the following information : 
 
* Console. This is the default tab, and gives you information about errors, log entries, memory usage or execution timings.

*
Load time. This is the request load time. It will display execution details in the body of the tab.

*
Database. The number of queries executed, the execution time, and if supported, a query analysis.

*
Memory. Total peak memory used by the request.

*
Files. The fully qualified name of all PHP files included, and their size.

*
Config. The contents of the configuration store at the end of the request.

*
Session. The contents of the session store at the end of the request.

*
GET. The contents of the $_GET array.

*
POST. The contents of the $_POST array.
Application profiling : 
Profiling your application is disabled by default. You can configure Fuel to activate the profiler via your applications config/config.php file.
'profiling'  => true,​

After the profiler has been enabled, you will see it pop up at the bottom of your browser window.
 
Database profiling :
Database profiling is disabled by default too. Database profiling is activated per defined database, and is activated by setting the 'profiling' option of the database configuration you want to profile in your config/<environment>/db.php to true.
'profiling'  => true,