Simplifying and Abstracting Your Code PHP Help

Are you done yet? Well, almost. The error printing is great. but take another look at the code in your main script, connectino.php:

Simplifying and Abstracting Your Code

That’s a lot of code to handle the problem. In fact. you have a good bit more code dealing with the error than you do dealing with things that go right. That’s not always a bad thing, but in this case, it’s just not necessary. Do you remember how this code originally looked?

Simplifying and Abstracting Your Code

This code has a line that does what you want. It also has a line if there are problems. Now multiply that by all the different places your code can fail; that’s a lot of error handling code.

So, can you get your error handling to be that elegant? It’s worth at try. Look closely at the code again and notice how regardless of what the error is, parts of the code will always be the same:

Simplifying and Abstracting Your Code

The only things that ever change here are the actual error messages. The rest-the variable names, the header call, and the building of the URL-are always the same. This seems like it would be a good time create another function, a lot like debug_print, to handle the messages.

Add this function to ,H)o_config.php, further expanding your utility script:

Simplifying and Abstracting Your Code

This bit of code is really just a variation on what you did with debug_print (page 239). You’ve taken something that’s essentially the same code, over and over, and put it into a nice, handy, easy-to-reference custom function. The only change is the addition of exit. This line ensures that regardless of how the calling script is structured, once the header redirects the browser to your error page, nothing else happens. The error page displays, and PHP stops whatever else it might have planned to do.

Now, you can simplify connect.php by quite a bit:

Simplifying and Abstracting Your Code

This code is a ‘neater, especially when you realize that it can fit into a single line in a terminal or editor. But. you can take this yet further:

Simplifying and Abstracting Your Code

Here, you’ve dropped the if statement and returned to the simple elegance of the or die you used to have, but with a much nicer function: your own handle_error.

redirect Is Path-Insensitive

There’s just one problem with the current incarnation of Connect.php and it looks like Figure 8-14. You might see just this when you tryout for yourself. You see a page indicating that something has gone wrong, but it’s sure not the page you were expecting.

This error is well known in PHP. Most web servers are set to treat any URL request that ends in php as a PHP request. That’s good, because it means that you don’t have to stash all your PHP scripts in one directory. But it’s bad, because the web server doesn’t see whether the URL that ends in .php matches an actual file. It just hands the URL over to the PHP program. But if that URL isn’t a pointer to a real file, PHP says, “I don’t have anything to run.” Or, more accurately, it says “no input file specified.”

redirect Is Path-Insensitive

Yet the Question remains: Why are you getting this? It has to do with this little bit of code in app.config.php

redirect Is Path-Insensitive

In this code, the path to show_error.php is relative to app_confiq.php. Because app_config.php is in the same directory as show_error.php, there’s nothing before the file name.

But this code is executed from your connect.php script, in (at least in the examples in this book). Therefore, the path from that location to show_error.php is show_error.php Even though the handle_error function is defined in app_config.php it’s run from the script’s contexts. The result? You’re looking for show in the wrong place.

But, if you change the path in app_config.php to work with Connect.php and you later have a different script in a different location, you’re going to get this same issue all over again. This begs the Question: How is handle_error very useful anymore?

What you need, once again, is a way to indicate a common property-the root of your site-and then relate the path of show_error.php to that with an absolute path rather than using a relative path, (And if you need a refresher on the difference between the two, see the box below.)

You can define your site root in app_config.php with a new constant:

redirect Is Path-Insensitive

Now, you should finally be able to see show_error.php via an error in connect.php, in all its glory. Check out Figure 8-15 for the result of all this work.

FIGURE 8-15

FIGURE 8-15

To finish up, take a blazing trip through all of your scripts and replace every bit of die and other error handling with calls to handle_error. Don’t forget to update database_collection.php to use handle_error, too:

redirect Is Path-Insensitive

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

Share the Story

Back to Top