Thanks for your blog post that is a good way to avoid the white screen issue.
What sort of error would i want to show in a production environment? Well, i like to use the error handling mechanism for recoverable errors. Say a controller method is called with incorrect parameters or a user tries to send data that is invalid or an email can't be sent. Unlike the php and application errors these are recoverable errors and it is often necessary to take some action after the error occurs. These are not application errors or php errors and should be distinguishable as being different. However since they can often occur in many different places in an application (controllers and models) it's nice to have a global error handling system to cater for them rather than having to add boiler plate code in all the places they occur (sending an email for example). I realize that there are ways to implement this type of functionality with the tools that cakephp offers its just that i thought that this was part of the error handling mechanism. On Feb 7, 10:42 am, ianh <[email protected]> wrote: > @Teknoid; subsequent to my earlier posting I did find your blog post > and changed from writing Configure::write('debug', 1) at the point of > calling cakeError to setting debug to 1 in the __construct() method of > app_error so many thanks for pointing out that this could be done. > > You asked what errors do you want to display; well the first main > thing to note is that in my experience, users hate it when they do > something and just get a white screen of death with no indication of > what went wrong. > > So with that said, this is an example use from the new version of > EventHQ (http://www.eventhq.co.uk) I am working on: > Users can normally enter an event to look at > (e.g.http://account-name.eventhq.co.uk/conference-name. If they mistype the > conference name or copy/paste it incorrectly or whatever and EventHQ > cannot find the event, use a custom app_error method to show a 404 > page together with a dropdown list of all events available for that > account that the user can choose from and navigate to. > > I accept that I could achieve exactly the same thing in other ways, > but it seemed to me that encapsulating all error-related functionality > (where I am lumping PHP/Cake/application errors into 'error-related') > into a single app_error controller and views is a really good thing to > do and a great piece of functionality to have. The CakePHP book also > seems to suggest that cakeError is there for exactly this purpose and > is intended to be extended with custom methods. > > So, the OPs question 'Is this really the desired behavior? It doesn't > seem to be documented?' still stands, although this thread and your > blog post have been exceptionally useful in showing how to workaround > the issue. > > ianh > > On Feb 6, 6:30 pm, teknoid <[email protected]> wrote: > > > What errors do you want to display to the user, while running in > > production mode? > > > That being asked, you might take a look here on how to handle this > > situation:http://teknoid.wordpress.com/2008/08/29/dealing-with-errors-in-cakephp/ > > > On Feb 6, 11:54 am, maxmil <[email protected]> wrote: > > > > I have found the same problem. > > > > Is this really deliberate? > > > > It takes quite a bit of power away from the cakephp errorHandling > > > mechanism if it is and is very naughty not to mention it in the error > > > handling pages of the manual! > > > > My solution has been to use: > > > > $this->render('/errors/custom_error'); > > > > instead invoking $this->cakeError. > > > > On Jan 16, 11:55 am, ianh <[email protected]> wrote: > > > > > Hmm. Just found the same thing. Seems to be to do with lines 110 to > > > > 117 in core error.php __construct method > > > > if ($method !== 'error') { > > > > if (Configure::read() == 0) { > > > > $method = 'error404'; > > > > if (isset($code) && $code == 500) { > > > > $method = 'error500'; > > > > } > > > > } > > > > > } > > > > > So if you trigger cakeError with a method like 'test' then that works > > > > fine unless Configure::read() (which seems to return debug by default) > > > > is 0 then it gets reset. So you can create a custom method in > > > > app_error called 'error' and that will work regardless of debug level, > > > > but any custom errors will only work when debug is > 0. > > > > > The code suggests this is intended but the book doesnt make any > > > > reference to it. Also the tests dont shed any light as of course tests > > > > cannot be run when debug is 0! Does anybody know what the intention > > > > behind this is please? > > > > > Anyway, as Mike says above, the solution Im now using is to include a > > > > Configure::write('debug', 1); line wherever I call cakeError for a > > > > custom method. > > > > > Thx, ianh --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CakePHP" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/cake-php?hl=en -~----------~----~----~----~------~----~------~--~---
