>> For the time being, I need to sort out how to maintain my querystring when I >> redirect. >>
To maintain the query string, don't redirect upon error? Swallow the error and display an error page with a http 500 header - There is a need for two types of error pages potentially, one for general errors that the application can still handle while still rendering a page suitable for the user to then navigate away from, the other is a fatal error page that really is nothing more than a static page (at which point its up to you how to display it)? >> > 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: >> > A recent observation of mine is that when in production if the bootstrap method swallows the error, the run method is still invoked which is unnecessary and causes other errors, so for example, $application->bootstrap()->run(); Its seems like the run method should check to see if the bootstrap was invoked successfully. >> >> 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: The error controller could respond accordingly based upon if it is an ajax request. I'd be less inclined to do that for the fatal error page? -- Greg
