Question

In the Zend Framework library, the current practice (circa 1.10.8) is that library components throw exceptions that extend Zend_Exception.

E.g. the Zend_Layout component throws a Zend_Layout_Exception

In my own ZF library, where I’m adding my own ZF components or extending existing components, I’m throwing a Mylibrary_Exception (it’s not really called that of course 🙂

I can see that they’re going to change some of that in ZF 2.0

http://framework.zend.com/wiki/display/ZFDEV2/Proposal+for+Exceptions+in+ZF2

My actual question is this:

Throughout my MVC application in my controllers/models/views, if I need to throw an exception (and this will be rare, because obviously I’ll be handling expected errors in a different way) – BUT if I do need to throw an exception here, what is the best practice in ZF?

should I just

throw new Exception("this is an exception");

or should I be creating Exception classes in my ZF modules, similar to how the ZF library is organised. i.e. they have exception classes for each library component, should I have exception classes for each application module?

application/modules/user/controllers/UserController.php

application/modules/user/forms/UserForm.php

application/modules/user/models/User.php

application/modules/user/views/scripts/index.phtml

application/modules/user/exceptions/Exception.php (class User_Exception)

application/modules/user/exceptions/SuperexampleException.php (class User_Exception_Superexample)

I’ve never seen anyone do anything like that before in ZF, so I’m not sure if it’s a good idea or not.

UPDATE:

To clarify my question further – when raising exceptions in the MVC part of the application (as opposed to the library) – are there any conventions regarding using specific exception classes (like the library does) vs just using the generic Exception class?

Answer 1

I’d suggest having some “generic” exceptions like (InvalidParameter, InvalidRange) Good starting point is czech framework called Nette.

Then add some app/user/action specific exceptions – like

• InvalidUserInputException – for states where user entered invalid value (like “-1” as quantity in eshop)
• NotFoundException – for states where something was not found
• etc.

Add special member variables to those exceptions – like id or data – and use them to employ exceptions as delivery for error messages.

$e = new NotFoundException('There is no user %s in here!');
$e->setUser('Frank');
throw $e;
// later in error controller
if ($e instanceof NotFoundException) {
    // set header to 404, display error message, etc
}

Good thing is that you can extend the exceptions anyhow you want and catch them in error controller anyhow you want (even better it’s using Interfaces)

class AccessDeniedExceptionimplements ILogableException
//...
throw new AccessDeniedException();
//in EC
if ($e instanceof ILoggableException) {
    $this->getLogger()->log($e->getLogMessage());
}