Add Debugging to Your Application PHP Help

You’ve got some error pages that are very helpful to your readers. But what about you? Certainly, you’re going to need to use your system, too. Although you want to have error pages that don’t scare off your users, there are times when you need to figure out what’s going on, not just in your code, but also on your front end. But, the error pages you’ve put in place are designed to shield users from seeing what’s going on at the script level. What you need is to figure out a way to show the real errors that occurred-in a way that only you can see.

Who’s Using This App, Anyway?

Remember that this chapter started out by talking about the kinds of errors that your users see. The idea was to avoid unappealing, cryptic-looking errors like this:

#1054 – Unknown column ‘firstname’ in ‘field list’

Sounds good …except when you’re developing the application. In fact, if you’re writing code, that’s exactly the type of error you want to see. It’s specific, helpful, and unlike your users, you aren’t intimated (certainly not any more) by some techy details. Put another way, you need a method to distinguish between debugging-when you’re writing and fixing code-and production. You could have a way to set your application’s mode. You could run in debug mode and see all the errors your script puts out, or you could run in production mode, in which error reporting isn’t turned on. Then, you could simply run in debug mode until it’s time to go live.

This arrangement is easy to set up; with app.config.php, you already have a nice central place to configure this sort of thing:

<?php
II Set up debug mode
define(“DEBUG_MODE”, true);
II Database connection constants
?>

This gives you the ability to make a single change to DEBUG_MODE and you get (or don’t get) error reporting across your application. Now that you have a way to set your mode, it’s time to make this new mode work.

Now You See Me, Now You Don’t

Unfortunately, you’ve done a lot of work, but you still haven’t solved one core problem: You need a way to display more information about an error to you and your programmer buddies without terrifying your users. Fortunately, you’ve laid some groundwork; the app.config.php file you created has a DEBUG_MODE, and that’s the key ingredient.

What you need is a way to print out additional error information if you’re in debug mode, To do this, you need to define a new function-call it debug_print-that only prints information if you’re in debugging mode. Add the following code to app.config.php

<?php
// Set up debug mode
define(“DEBUG…MODE”, true);
// Database connection constants
function debug_print($message) {
if (DEBUG_MODE) {
echo $messagej
}
}

With this function in app.config.php, it’s available anywhere in your own code. All it does is selectively print a message; if debugging is enabled, it prints, and if it’s not, $message never sees the light of day.

Next, you can add some additional information to your show_error.php page:

Now You See Me, Now You Don't

With this function in app.confiq.php, it’s available anywhere in your own code. All it does is selectively print a message; if debugging is enabled, it prints, and if it’s not, $message never sees the light of day.

Next, you can add some additional information to your show.error.php page:

Now You See Me, Now You Don't

Then, down in your HTML, selectively print out this additional information:

Now You See Me, Now You Don't

Finally, you can put all this together: You have an error page, you have a means of printing information’ only if debugging is enabled, and you have app.config.app to tie everything together. Before you’re ready to conquer and selectively debug the world, though, there’s something else to take care of. It’s not quite error handling, but just plain, good coding.

Moving from require to require_once

If you look carefully at database_connection,php. you’ll see this line at the top:

require ‘app_config.php’;

This means that any script such as the one that follows here, in turn requires app.config.php as well.

require’ ../../scripts/database_connection.php’;

So, if you wanted to get the setup from app_config.php in a script that already requires database_connection, you technically don’t need to explicitly require app.config.php.

But-and this a -big but-you’ve now hidden what’s called a dependency in your code. Even though you’re not requiring app.config.php explicitly, you’re writing code assuming that app.config.php has been loaded. Suppose that you change a script to not use a database; the natural next step would be to remove the require for database_connection.php. Because your script no longer uses a database, requiring database_connection.php wouldn’t make sense. With that removal, however, you also lose app.config.php which causes a hidden problem that wouldn’t show up until you realized none of your helpful constants and error messages are defined.

For this reason alone, it’s a good idea to always be explicit in your requirements. To be sure, there’s an obvious concern here: app.config.php will end up being required t-v«:e in database-driven scripts. You’ll require app.config.php as well as database_connection which in turn requires app.config.php again.

To get around this, you can use require_once instead of require in all your utility scripts. Therefore, in your main script-in whatever script your main code exists-use the normal require:

// main script you’re writing code
require ‘../scripts/app_config.php’;

Then, in any utility scripts that also need app_config.php, you would use require_once:

// database_connection.php and any other utility scripts
require_once’ ../scripts/app_config.php’;

The require_once line checks whether the specified script has already been included (through include or require). It only includes the script if hasn’t already been loaded. This ensures that app_config.php is only loaded once.

But, there’s yet another problem: sometimes you have one script-like create_user.php-call another script-like show; user.on». In this case, you have two scripts that probably both use require, which will result in errors about constants being redefined. Is this a problem? Should you rethink and refactor app.config.php Should you abstract out those constants into another file or move them into Honestly, you can just get around all of this by using require_once in your scripts. This rule of thumb is a good way to ensure that an app.config.php is never loaded more than once. It also has another side effect: you’re no longer trying to figure out which version of require to use. Just use require_once, unless you have a specific need to require something multiple times. That’s something that rarely happens, so going with require once as your standard is a good idea.

In fact, you could have just started by using require_once right from the beginning. But, then you’d have no real idea why you’re using that over require. By running through this process of actually seeing how some of your scripts call some of your other scripts multiple times (like the example on page 171, you can now explain to your coworkers why they too should almost always use require_once in their PHP scripts.

 

Posted on January 11, 2016 in When Things Go Wrong (and They Will)

Share the Story

Back to Top
Share This