Click to See Complete Forum and Search --> : Defensive Coding
NogDog
08-11-2005, 01:14 PM
I've put together a first draft on a little article about defensive coding in PHP. I'd appreciate any feedback on the content: does it make sense, are the examples clear, any glaring omissions, etc.? I'm not worried about things like spelling and grammar at this point, I'll clean that up later.
Thanks
And here's the article: http://www.charles-reace.com/article.html
Shmohel
08-11-2005, 01:32 PM
Very well written ND. I think I may take up your idea of turning all error emssages on while scripting. Thanks!
BeachSide
08-11-2005, 05:44 PM
My absolute favorite line... I am still laughing over this...
We want to output a "nice" error message that looks professional, implying that everything is under control and we're sure it will be better in the morning.
rch10007
08-12-2005, 11:36 PM
I think you are going to help save alot of computers from being thrown out the window with this article. Ok, maybe only mine - but it's a start!
ShrineDesigns
08-13-2005, 01:09 PM
One of the common mistakes I see many novice PHP developers make is to assume that everything should work as coded.awsome openning sentance, great minds think alike lol, great job nogdog
Jeff Mott
08-13-2005, 01:42 PM
...and wherever you currently have die("some message") just change it to error("some message"[, TRUE|FALSE])I'm not up on my PHP, but are you able to override the functionality of core functions? For instance, instead of changing every single die to error, could you instead define die to do something different?
NogDog
08-13-2005, 04:36 PM
I'm not up on my PHP, but are you able to override the functionality of core functions? For instance, instead of changing every single die to error, could you instead define die to do something different?
I seem to recall that PHP does not allow this, but I'll have to look into it to be sure, as that's a good idea.
Stephen Philbin
08-13-2005, 05:02 PM
Well written. Clean and clear. I like. :D
I know you're probably already on it, but I think a section on SQL injection and promotion of mysql_real_escape_string() over magic quotes GPC or addslashes (assuming MySQL is the database in question of course) would definitely be a good thing.
Actually, I think making a sticky with links to well written and clear articles like this, on some of the important basics of PHP would be a good thing.
Sheldon
08-13-2005, 05:05 PM
I like the article Nog Dog, iI like the easy way you have written it so that even a novice (Much of myself) can understand what you are on about. i like how you say to include some of the variables in the error message.
Nice work!
Sheldon
bokeh
08-13-2005, 05:10 PM
Instead of using die() at the coding stage and changing later you could use error() but have:
function error($error)
{
die($error);
}
This would save changing die() to error() after debugging has finished. All that would be needed is changing the above function to your function.
Does this make any sense?
NogDog
08-13-2005, 05:32 PM
Instead of using die() at the coding stage and changing later you could use error() but have:
function error($error)
{
die($error);
}
This would save changing die() to error() after debugging has finished. All that would be needed is changing the above function to your function.
Does this make any sense?
Yes. And I've confirmed by experimentation that you can not redefine a function.
Maybe a follow-up article in the works with some of the ideas here? I think I want to avoid introducing too much in one article.
Thanks to all for the feedback.
Sheldon
08-13-2005, 05:41 PM
Yes that does make sence, saves going throught and making changes to everything.
But one question? would that mean that the same error message would come up with everything?
Sheldon
Genixdeae
08-14-2005, 12:00 AM
good job nogdog, much like everyone else said, you did great on it.
:)
NogDog
08-15-2005, 10:06 AM
Instead of using die() at the coding stage and changing later you could use error() but have:
function error($error)
{
die($error);
}
This would save changing die() to error() after debugging has finished. All that would be needed is changing the above function to your function.
Does this make any sense?
This inspired me to come up with the following function:
function error($text, $fatal = FALSE)
{
if(!defined('DEBUG') or DEBUG == FALSE) # not in debug mode
{
# ouput error text to log file:
$path = "C:\\"; # specify where log files will be saved
$this = array_pop(explode("/", $_SERVER['PHP_SELF']));
$file = "$path$this.log";
error_log(date("Y/m/d-h:m:s") . " --> $text\n", 3, $file);
if($fatal)
{
$msg = <<<EOD
<p class="error">We're sorry, but an unrecoverable error occurred processing
your request. If this problem persists, please contact the
<a href="mailto:{$_SERVER['SERVER_ADMIN']}">webmaster</a>.</p>
EOD;
die($msg);
}
}
else # in debug mode
{
if($fatal)
{
die("<pre>ERROR: $text</pre>");
}
else # not fatal, so just output error text
{
echo("<pre>ERROR: $text</pre>");
}
}
}
Now all I need to do is incude() it into any script, and if I want to run in debug mode (have any errors reported directly to the normal output) just define a constant DEBUG as TRUE; otherwise it will run in non-debug mode, outputting all error text to the log file:
include "include.php"; # file that includes error() function
define('DEBUG', TRUE); # run this script in debug mode
# ... rest of script follows
# sample error situation:
mysql_query($query) or error("Query failed: " . mysql_error(), TRUE);
Jeff Mott
08-15-2005, 09:41 PM
Just another suggestion (going back to my Perl roots): using a boolean for fatal or not is not going to be very readable in the main body of code.... or error("don't work", FALSE);
... or error("also don't work", TRUE);Perhaps instead you could write two different functions for the simple purpose of readability.... or Error("don't work");
... or FatalError("also don't work");In Perl this would be synonymous with the operations die and warn.
ShrineDesigns
08-15-2005, 11:07 PM
or you could do something like$var = '';
if(empty($var))
{
error('$var is empty', E_USER);
}
unset($var);
if(!isset($var))
{
error('$var is not set', E_FATAL);
}
NogDog
08-16-2005, 12:24 AM
Hmm...maybe I'll add...
define('FATAL', TRUE);
define('NONFATAL', FALSE);
...to my include file, then I can just call the error function as...
error("error message", FATAL);
# or #
error("error message", NONFATAL);
Jeff's idea of two functions has some merit, too, maybe actually calling them warn() and error(). Guess I just have to decide which way I prefer: one function with 2 parameters, or two functions with one parameter.
Stephen Philbin
08-16-2005, 12:31 AM
I'd go for one function with two parameters. I actually think TRUE and FALSE are more readable because of the casing making them stand out and if you're been doing this sort of thing for longer than five minutes, your eye has probably already trained its self to spot a TRUE in a haystack from the other side of the continent you're on.