These explanations are very helpful. Thanks Ralph.
On Thu, Dec 16, 2010 at 6:24 PM, Ralph Schindler <[email protected]>wrote: > 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 >> >
