Thanks Ralph,
This is very helpful. I will have to come back to this issue later on,
especially as I get a better handle on the framework, in general. You seem
to think that using the error handling functionality that comes with the
framework is the way to go. I am sure you will be vindicated on my end at
some point, but for the time being I will embrace my stubbornness and
proceed by wrapping the the run call with a try/catch. I just feel like the
ErrorController limits itself too much in terms of what errors it catches.
For the time being, I need to sort out how to maintain my querystring when I
redirect.
Thanks,
Jeremy
Ralph Schindler-2 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
>
>
--
View this message in context:
http://zend-framework-community.634137.n4.nabble.com/Error-handling-in-Zend-tp3089950p3091683.html
Sent from the Zend Framework mailing list archive at Nabble.com.
