Yes, we can actually disable error messages in PHP, and some of you beginners are probably confused to why we do such a “silly thing” to disable them. Is it not better to show the error messages? If we disable error messages, then how the heck do we know when errors happen?

Well, you need to understand the world of software development a little more. In the development side, we can show all kinds of error messages we want, it is better when developers and testers pick those up.

But when it comes to actual production systems, some people choose to hide the error messages for a “graceful system”, so that it “crashes gently and quietly”, without scaring users away. So now that you know, don’t switch on the error display in production systems, unless you really have to.

ERROR SETTINGS

Now, following up on “how do we know if errors have occurred”, there are 6 settings in the php.ini file that you have to know first:

display_errors = On
error_reporting = E_ALL
display_startup_errors = On
html_errors = On
log_errors = On
error_log = PATH/ERROR.LOG

• display_errors Show the error messages on the screen.
• error_reporting Types of errors to show if display_errors is on. Will go through more of this below.
• display_startup_error This one displays startup errors, not runtime errors.
• html_errors Format the error messages in HTML format?
• log_errors Keep errors in a log file.
• error_log Where to keep the error log file.

So typically:

• We go “full force all error reporting on” a development server.
• Hide with display_errors = Off but log_errors = On a production server – That is how we can still track errors, from an error log file.

ERRORS REPORTING LEVELS

We can set the level of reporting with error_reporting, and there are generally 3 “main levels”:

• E_ERROR Fatal errors.
• E_WARNING Warnings, non-fatal errors.
• E_NOTICE Notices, non-fatal.
• E_ALL All kinds of errors.

Take note that the above is not all to it, check out the official PHP manual for the full list. But for now, we can play with the above to tweak the level of reporting:

; Report all errors
error_reporting = E_ALL

; Report critical errors only
error_reporting = E_ERROR

; Report critical errors and warnings
error_reporting = E_ERROR | E_WARNING

; Report all errors, except notices
error_reporting = E_ALL & ~E_NOTICE 

FATAL ERRORS

Fatal errors will abruptly stop the script and break the system – There is simply no way that you can miss fatal errors. Even if the error reporting is turned off, a weird broken script is just going to raise eyebrows. Fatal errors commonly include undefined functions and missing files.

SYNTAX ERRORS

Stupid things such as missing a semi-colon or comma. 

WARNINGS

Warnings are non-critical errors, but still of significant importance. For example, putting a string into a function that seemingly needs numbers instead – While this will not break the system, it might end up with the wrong results.

NOTIFICATIONS

One of the most annoying kinds of “errors”. Notifications are often of little importance, and they are just here to remind you of stuff like “you have not defined this before”, or “this has been deprecated, not recommended”.

SILENT ERRORS

There are truly deadly errors. They do not throw any error messages, are hard to spot, and will continue running. You will only realize that there is an error when the scripts do not produce the kind of results that you want. For example, a small typo mistake can result in a significant “silent error”.

RUNTIME ERROR REPORTING

If you really need to display the errors on the productions server, and only for a particular script – Yes, we can do that with a few lines of ini_set and error_reporting.

Just remember to remove these lines after you get a screenshot of the error message.

DUMP THE VARIABLES

So, what is in an array? What is in the session that is causing problems? print_r and var_dump are your best friends.

 [
    "name" => "Foo bar",
    "qty" => 99
  ],
  "234" => [
    "name" => "Doge",
    "qty" => 88
  ]
];

// What is in the session?
print_r($_SESSION);
// More details using var dump
// var_dump($_SESSION);
?>

CODE SECTIONING, DIVIDE AND CONQUER.

Try to write your code in sections – This is not just a debugging technique, but also a good practice. Remember the silent errors? Trying to find that small typo error is exactly like looking for a pin in an ocean of code.

But when we section our code, we can use echo, print_r, or var_dump to manually confirm the values and output at each section of the code. Use this in conjunction with die() or exit() to stop the script at each section – Slowly moving to the next section only when we confirm the output is correct at each stage.

USE A GOOD EDITOR OR IDE

This is not a technique, but quite a common sense thing. A good code editor will highlight all the errors as you type, even help you to format the code. This will filter out all the silly mistakes, such as missing semi-colons.

CUSTOM ERROR LOG

Remember from earlier that we can log the errors “in the background” to a file with log_errors and error_log? Well, we can actually use the error_log() function in PHP to manually create an error entry. For example, we have a script that will connect to another server, and this will log an error entry when the connection fails.

 "https://DOES-NOT-EXIST.com/dummy.php",
  CURLOPT_RETURNTRANSFER => true,
  CURLOPT_HEADER => false
]);
$result = curl_exec($curl);
if ($result === false) {
  // ERROR LOG
  error_log("Failed connecting to https://DOES-NOT-EXIST.com", 0);
} else {
  // OK
}
curl_close($curl);
?>

Very useful if you want to monitor certain things or even the reliability of certain services. By the way, we can even send notification emails with error_log(), check out the official PHP manual for more options.

GRACEFUL FAILURES

When PHP throws an error, it’s not the end of the world. This should be in most of the basic tutorials, but a quick recap – With a try-catch-finally block, we can gracefully handle the exceptions.

 PDO::ERRMODE_EXCEPTION,
      PDO::ATTR_DEFAULT_FETCH_MODE => PDO::FETCH_ASSOC,
      PDO::ATTR_EMULATE_PREPARES => false
    ]
  );
}

// ERROR - DO SOMETHING HERE
// THROW ERROR MESSAGE OR ALTERNATIVE
catch (Exception $ex) {
  print_r($ex);
}
?>

SUPPRESSING ERROR MESSAGES

Finally, this is not really related to debugging, but we can suppress error messages by adding a @ in front of the functions. For example, when we open a non-existent file:

INFOGRAPHIC

SOURCE CODE DOWNLOAD

Click here to download the example source code, I have released it under the MIT license, so feel free to build on top of it or use it in your own project.
 

The post How to Debug PHP Code – Ninja Techniques You Should Know appeared first on Code Boxx.