Hey Jeremy,
Ultimately, it all depends on what kind of exceptions are thrown, where
they are thrown, and how the framework is setup to handle them. There's
lot of moving parts, and a default application already takes care of
them form you for the most part.
Out of the box, the Front Controller is set to NOT throw exceptions.
Instead, it catches any exceptions thrown during dispatch, stores them
in the response object, and forwards the dispatch loop to the
ErrorHandler/ErrorController (which is on by default).
Furthermore, while you are in 'development mode' (as setup by your
index.php, typically by an environment variable), your application will
instruct the ErrorController to display exceptions, you'll see this line
in your application.ini:
resources.frontController.params.displayExceptions = 1
which is overriding the default from production which is false.
I would suggest sticking with the initial project structure and default
values in all honesty. The setup is quite good, and very informative
when there are errors occurring.
So lets look at where exceptions are thrown:
[index.php is hit]
$application is created.
$application->bootstrap() is run.
* exceptions can be thrown here form any resource that
could not be setup either by configuration (resource.* values)
or by Bootstrap::_init*() methods. Either way, you can't trust
you have any part of your application setup, in this case, this
is beyond a 500 error. These types of exceptions should never
be thrown in production anyway. If you are getting exceptions
from bootstrapping, you need to take care of the problem sooner.
$application->run() is called.
* This effectively is Zend_Controller_Front::getInstance()->run();
For all intents and purposes, any exception thrown here is a 500
or 404 error, and generally can be handled by ErrorController.
* The only exceptions that make it hard to display a full page
would be exceptions thrown FROM the ErrorController, or exceptions
throw FROM the Layout. As you can see, if neither of those
are in good working order, it's hard to use them to build a page.
If you want to use a try/catch block in your index.php, I would use it
only on the ->bootstrap() call of the $application, not run() as nothing
will be emitted. If you insist on throwing exceptions and catching them
in the index.php, add this value to you application.ini:
resources.frontcontroller.throwExceptions = 1
Hope all that helps,
Ralph Schindler
On 12/15/10 3:43 PM, jalexander3 wrote:
Hello,
I have read about the ErrorController that comes standard with the
framework. It seems to only handle certain errors pertaining to missing MVC
components--that's fine, I can use that. However, for my purposes I think I
need a better understanding of URL rewriting and how the framework works in
general.
Anyway, here is what I have done in terms of error handling. It's pretty
simplistic.
My application entry point is wrapped in a try-catch. When an exception pops
anywhere in the application, I run a couple of procedures that then send an
email and log the message, etc.
/* Wrap the entire application in an error handler*/
try
{
$application->bootstrap()
->run();
}
catch (Exception $e)
{
require_once 'ErrorHandler.php';
HandleException($e);
}
What I really want to do is just pop a jquery dialog box on the page that
pops the error (or the previous page if there is something like a 404
error). In order to do this I am trying the following:
catch (Exception $e)
{
//require_once 'ErrorHandler.php';
//HandleException($e);
/*
Get the current layout and relocate to it,
passing a flag to display the error dialog
*/
$currentLayout=$application->getBootstrap()->getResource('layout')->getLayoutPath();
header('Location: ' . $currentLayout . '?action=error');
}
The problem is, I don't understand enough about what is going on behind the
scenes. $currentLayout points to the layouts directory. The querystring is
lost as "http://localhost/TAW/application/layouts?action=error"; then points
back to a valid page.
At the end of the day, it doesn't make sense to point back to a "valid"
page...I would probably point to an "error" page that utilizes a defined
layout. But in any case, I still need to maintain that querystring.
Does anyone have any thoughts about this entire process? Some best
practices? Or more specifically, how to resolve the issue I am having
concerning the querystring?
Much appreciated!
Jeremy
