How Do You Kll EE's 40-Headed Error-Reporting Dagon? [closed]

Question

Tbe main think I love about errors not displaying them on the screen viewing production systems. My phone rings less, people are happier. Everything is logged, nothing to the screen. We have a great working relationship thoese errors and me

****Except**** one of our apps, called EE or ****ExpressionEngine****.

The documentation is EllisLab's patented sleek, competent-looking airhead documentation It looks sounds great. If they would add the rest of the critical information then it would be good. No hint, except experience tells you, there are well known (but not to you) absolutely critical elements for getting the system work right. Not much is worse than doing a long process to a T, and your system is not working and no have idea why. Most of the these holes in the story are small, that is how they are forgotten and left out. Error handling from Ellis lab is the opposite of small. It is like the Jolly Green Giant, who smiles, but you don't want him overt for dinner, he is to freaking big. EllisLab's error handling is their way making themselves into a Komodo Dragon. The only thing you want from them both is the same thing: to go away and if you never see one or the other again, doesn't matter which, or if it's both, non-contact for the rest of your life will not be the cause of a problem.

If their documentatiin did not double as marketing material, the phony could get edited out. EllisLab's Error reporting documentation is excellent in making me think its all info will put me in control of my system. Error_display on Error_display off, sounds easy, display means to the screen so your turn it off, what else is there to know?

"Excuse me, but could tell if you know of any error-message pipelines in the area? Some people are getting error-messages in their water. It looks it would make them sick, "Oh, it's just a php notice.": But I turned those off in the php.ihi file! EE looks at me like that is supposed to mean something, and I it thought. I never was thinking no one should be able to override anything in the app but that comes with responsibility exercised poorly by Ellis lab. So who was begging for error handling that made it became such a big part of their systems? Ellis lab has some kind fetish for error handling. Like most fetishes, I don't care what people do, but when a fetish, no matter what it is, results in foreign goo on computer screens I am responsible for filling with pixel-perfect content, then i have a problem, because it makes my phone ring when I had made plans to move forward, not backward, fixing an unnecessaery broken error handler. The errors are not the problem it i the error handling, especially screen diplay

So my question is: How do you kill EE's 40-headed error-reporting dragon? there must be an addon to fix that parts that don't work but also are not needed.

Answer 1

Umm index.php

/*
 * --------------------------------------------------------------------
 *  Error Reporting
 * --------------------------------------------------------------------
 *
 * PHP and database errors are normally displayed dynamically based
 * on the authorization level of each user accessing your site.  
 * This variable allows the error reporting system to be overridden, 
 * which can be useful for low level debugging during site development, 
 * since errors happening before a user is authenticated will not normally 
 * be shown.  Options:
 *
 *  $debug = 0;  Default setting. Errors shown based on authorization level
 *
 *  $debug = 1;  All errors shown regardless of authorization
 *
 * NOTE: Enabling this override can have security implications.
 * Enable it only if you have a good reason to.
 * 
 */
    $debug = 0;