0

After so much time developing in PHP, I have become curious as to why the default error settings in PHP up until PHP7 were acceptable.

The default error handling regarding errors and warnings is to print to STDERR and continue as if nothing happened. Why is this considered proper? How do the developers of PHP come to this conclusion? Notices and warnings always mean SOMETHING, usually that state has be corrupted in some fashion.

I believe this creates confusion in the eyes of developers for no reason. Consider the following posts on the stacks:

Should PHP 'Notices' be reported and fixed?

Turn off warnings and errors on php/mysql

How do I turn off PHP Notices?

Notices and warnings should be converted into exception objects so that you can act upon what they mean, rather than let new developers be led to believe that they can be safely ignored.

Consider the following method:

//This method is the default error handler for the entire application
//It throws an exception instead of an error
//$level         = Error level that the system is throwing (Warning,Notice,All,ect)
//$message       = Error message that the server is passing
//$file          = File in which the error occured
//$line          = Line in which the error occured
//array $context = Array of variables that were available in the scope of the error
public function ErrorHandler($level,$message,$file,$line,$context)
{
    switch($level)
    {
        //throw a PHPNoticeException on notices
        case E_NOTICE:
            throw new PHPNoticeException($message,$level);
        break;
        //Throw a PHPWarningException on warnings
        case E_WARNING:
            throw new PHPWarningException($message,$level);
        break;
        //Throw PHPExceptions on everything else
        default:
            throw new PHPException($message,$level);
    }
}

Utilizing the above, one can catch and handle errors and notices. However, in their default state, a programmer is unable to act upon any warnings or notices that occur, or even know that they occurred in the first place.

Stating my questions again, why are silent errors the default behavior? Why was this decision made by the developers of PHP? It leads developers to believe that notices and warnings are unimportant. I think this to be irresponsible and reprehensible.

Community
  • 1
  • 1
steve
  • 290
  • 1
  • 11
  • Could be because they considered it safer to assume a production environment rather than expose users to attacks based on information revealed by errors. It is not difficult to drop a line of code at the top of the script to activate on screen error reporting for development purposes. – Steve Dec 31 '15 at 22:00
  • @Steve I'm not sure that I understand what you are getting at. Would corrupted state be safer than throwing an exception? If they are not catching those exceptions that is the programmers fault. In my opinion it is not the language developers job to attempt to fix bad developer code. So instead of reporting corrupted state, it throws it in a log silently and continues. This is better? – steve Dec 31 '15 at 22:06
  • 1
    I'm not really making any qualitative comment rather just offering a possible reason why in the modern environment where hacking is so rife, why the language developers might have decided that the risk of open error reporting exposing sites to attack outweighed the risk of poor code development. They thereby put the responsibility on the programmer to keep an eye on errors proactively and display errors only when needed in the development phase. Clearly a corrupted state is not a good thing but they seem to be assuming that developers should take responsibility for identifying faults. – Steve Dec 31 '15 at 22:14
  • @Steve That kind of makes sense, but it does not seem like a logical conclusion to make, as programmers would by default have no way of identifying and handling the faults, they fail silently. The ONLY way to be able to identify them is to change the default behavior. It would make more sense for them to default uncaught exceptions to get logged to the error log. At that point, even poor code would not be able to expose vulnerabilities. But broken code would be more obviously broken, and I believe this to be a good thing. +1 for the breakdown. It is likely an accurate estimation of events. – steve Dec 31 '15 at 22:20
  • I'm not at the heady level of language development but notice that many posts have some quite angry and indignant comments often aimed at newbie programmers, berating them for not having error reporting turned on. http://php.net/manual/en/language.errors.php7.php says: "if there is no default exception handler, then the exception will be converted to a fatal error and will be handled like a traditional error." Maybe I have misunderstood but never had a problem with developing code on a server with error handling on by default and migrating it to my production server which doesn't. – Steve Dec 31 '15 at 22:25
  • @Steve Now I'm really confused. Why would one ever want to turn error reporting off?? Production code should never throw notices or warnings so leaving it on shouldn't matter. My question was basically why they decided not to create exception objects out of the notices and warnings, and instead silently write them to a log with no means of programmatic acknowledgement. If you view my comments as in some way malicious towards new programmers, then you are completely misunderstanding where my frustrations lay. – steve Dec 31 '15 at 22:35
  • No I didn't think that - it is simply something I have seen many comments about. I was looking at the references you gave and at Boris Guéry's remark: "In a production environment you SHOULD NOT display ANY notices. Even if they crash your application." I am probably not really qualified to give an answer and have probably also confused error reporting with error display. These were only intended as polite thoughts and I had better bow out of this discussion. I hope others will be able to give you better insights. Happy New Year. – Steve Dec 31 '15 at 22:53
  • Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/99436/discussion-between-steve-and-steve). – steve Dec 31 '15 at 22:54
  • Fraid I am off out for New Year festivities. Hope you can get some good answers - it is an interesting topic! All the best for 2016. – Steve Dec 31 '15 at 23:00
  • @Steve I was just apologizing, clarifying, and thanking for the fun conversation. Happy new year to you as well. Thanks again! – steve Dec 31 '15 at 23:02
  • Nothing to apologise for - it is an interesting topic with many varied and hotly held views! Best of luck! – Steve Jan 01 '16 at 00:30
  • 1
    A late but possibly relevant thought is that even though your code might be perfect in the current default configuration, if you do not track items that are depracated, then you could still be at risk of errors being shown - e.g. when `split();` was depracated in favour of `explode();` errors would appear until the user updated their code, though none were there before. Perhaps defaulting errors to "off" or "silent" gives greater freedom to the language developers to make such changes without risk to users. – Steve Jan 08 '16 at 14:30

0 Answers0