displaying errors

PHP has a setting named display_errors that allows one to specify if various error messages should be sent to the output or not. It is recommended to keep it off, especially for the public sites, since it may reveal too much information about the application, and looks awful when seen on a public site.

However, for a developer an error report shown in time and place may prove quite valuable and usually is easier to work with then logs, etc. Of course that would mean – keep errors on in development, off in production. OK, then what we do if something weird happens in production and we want to see the errors, but we don’t want others to see them?

ASP has an interesting feature here – it allows you to display detailed error page only when accessed from local browser, but display something generic when accessed from “outside”. Maybe PHP could have some setting like display_errors=local which would enable display_errors for requests originating from developer machine but would disable it when outsider accesses it? Of course, this should be carefully done to prevent security problems, but I have a feeling it might be useful.

This can be done with an extension or even user-defined prepend script, but I think system-level mechanism might help people to use it correctly and avoid embarrassing themselves with publicly-displayed errors while keeping the stuff easy to spot for developers. Would that be useful?


11 thoughts on “displaying errors

  1. Pingback: Richard Heyes’ Blog: Displaying Errors (based on hostname) | Development Blog With Code Updates : Developercast.com

  2. In PHP 5, you can register an error handler class and handle all errors as exceptions. Just catch the exceptions and log them (or display them if you wish).

  3. Yeah, that way would work better.

    Anyway, I agree with Robert. The only reason its really useful in ASP.NET is because it fires up the debugger and allows you to debug straight away.

    I wouldn’t want to risk seeing a different view of a live website. Development (testing if you can have 3) and Production servers are the solution really. Display everything in dev and hide it in production.

    It’s more important to make sure all errors are logged and checked.

  4. You can also implement set_error_handler / set_ exception_handler . I don’t have any problems with finding errors.

  5. @ Dougal: Why not real netmask matching?

    $masks = array(
    array('' , ''), // loopback
    array('', '') // LAN

    function mask_matching($ip, $masks) {
    $ip = ip2long($ip);
    foreach($masks as $mask)
    // if ((ip2long($mask[1]) & ip2long($mask[0])) == ($ip & ip2long($mask[0])))
    if (!(ip2long($mask[0]) & ($ip ^ ip2long(mask[1])))) return true;
    return false;

  6. Hey Stas,

    I think because most PHP installations are on a non-Windows environment that is typically accessed by SSH, this feature wouldn’t really see much use. This type of feature is useful in ASP because developers can RDP into the server and load up IE to look at the site from the server itself. Most environments that PHP is deployed in don’t necessarily have that capability. I guess someone could use SSH + Lynx to look at the site, but that’s not the same as using RDP and a fully graphical browser to inspect your site.

    How about a way to specify a collection of IP Addresses to display errors to? Although, I think that would be overkill for a system-level option, when this is easily implemented at run-time and wouldn’t make a difference to normal users.

  7. This could be implemented quite easily in code for a specific range of IP addresses.

    To make a fully functioning thing all we need is to detect if an IP is on the local network.

    The following would probably work for 90% of cases…

    $ip = $_SERVER[‘REMOTE_ADDR’];
    $check = substr($ip, 0, 7);

    $local = “192.168”;
    $local2 = “127.0.0”;

    if($check == $local || $check == $local2){


    } else {



    This could be extended with regular expression matching so you can add ranges of IP’s… If I wasn’t feeling so lazy I’d write that too.

Comments are closed.