-- jalexander3 <[email protected]> wrote
(on Thursday, 16 December 2010, 01:23 PM -0800):
> 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.
The ErrorController is not actually "catching" exceptions. That's
happening in the front controller.
What the ErrorController does is create a "switch" for acting on
specific types of exceptions. By default, we segregate these into two
categories:
* "Page not found" (404) type errors -- controller or action method
missing
* "Application" (500) type errors -- everything else
Additionally, we provide hooks to allow you to log exceptions, using
whatever log writers you've configured.
You can customize in two different places:
* Add additional cases to the switch statement for specific types of
exceptions you wish to handle differently. As an example:
case ($errors->exception instanceof AclException):
$this->getResponse()->setHttpResponseCode(401); // Unauthorized
$this->view->message = 'Unauthorized';
break;
Basically, the above would look for an exception of type
"AclException", and, if matched, set a "401 Unauthorized" response
code and message.
This allows you to set more specific response codes and custom
messages when reporting the errors in the web display.
* Alter the view script (application/views/scripts/error/error.phtml)
You can alter the error controller to pass in the exception, which
allows you to display custom messages in the view script based on the
error type.
What Ralph was getting at is that the solution present in the framework
is quite flexible -- you may simply need to customize it slightly for
your own needs. Use it as a _blueprint_.
> 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.
>
--
Matthew Weier O'Phinney
Project Lead | [email protected]
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
