Monthly Archive for January, 2008

Update: Updated the class to have a cleaner code syntax.

Recently, I needed a different way of processing my own defined exceptions in symfony. The cleanest solution was to implement a symfony filter, as I didn’t feel like try-catching every action available in my application :)

First thing to do is let symfony know when we can enable the filter.
Edit apps//config/app.yml and add the following:

all:
.global:
  exceptionCatcherFilter: on

Next up is writing the actual filter.
Create apps//lib/exceptionCatcherFilter.class.php:

class ExceptionCatcherFilter extends sfFilter
{
    public function execute($filterChain)
    {
       if (sfConfig::get('app_exceptionCatcherFilter')) {
           try {
               $filterChain->execute();
           } catch (sfStopException $e) {
               // This is an internally used symfony exception and shouldn't be blocked
               throw $e;
           } catch (Exception $e) {
                // Do something with the exception, other than just throwing it
           }
       } else {
           $filterChain->execute();
       }
    }
}

Basically, this checks if we have enabled our custom filter, then tries to execute it. If it does throw an exception, the exception gets catched. When the exception is not of class ’sfStopException’, we can do something with it (for example, log it to a database or send mails or whatever). If we don’t have the filter enabled, the chain should still move on and pass execution to the next filter in the chain.

Last step that needs to be done is placing our filter somewhere in the chain of filters that is active in our application.
Edit apps//config/filters.yml:

rendering: ~
web_debug: ~
security:  ~
exceptionCatcherFilter:
class: ExceptionCatcherFilter
cache:     ~
common:    ~
flash:     ~
execution: ~

This is, of course, a very simple version of such a filter but it does the job and can easily be extended to do whatever you need.
The current context is retrieved by: $this->getContext();, so you should have a look at that too.

The guys over at Nexen have their PHP statistics ready for december 2007. They give a pretty good impression on how much PHP is used on websites worldwide, and what the trends seem to be. Only one thing I found remarkable: only 27% of the servers running PHP are running PHP5! Good thing though: PHP 5.2.5 is gaining the most website increase in december, so we’re going the right way!

I’d say, with 19 days to go until PHP4 will reach end-of-life, three quarters of the PHP-using world better start making the switch :)