break and continue are great and are often ignored. They can shorten code bigtime. Their optional numerical arguments are great. Without using them, one may end up really long code that is much harder to debug.
Last edited by Merve; 01-09-2004 at 07:25 PM.
"A proof is a proof. What kind of a proof? It's a proof. A proof is a proof. And when you have a good proof, it's because it's proven." -- Jean Chrétien
You may need to differentiate between error levels - such as errors generated by a form, a 'no results returned' error, etc. vs. system or database errors.
Use a generic error handler to customize error handling. You can already control error handling through PHP, but you might want generic application-level error handling. My scripts use a lot of templating stuff, but something along the lines of:
functions.php
PHP Code:
function s_error($msg='Undefined Error', $kill=false, $priority=3, $log=false)
{
switch($priority)
{
case 1: // Alert the troops
log_error($msg,$priority);
sound_the_alarms($msg);
die('We might not be back for a bit.');
case 2: // Unrecoverable system error
if($log) log_error($msg,$priority);
die('System Error: ' . $msg);
case 3: // User / general error
if($log) log_error($msg,$priority);
echo "Sorry, an error occurred: " . $msg;
break;
default: // Or however else you want to handle this by default
die('Unspecified error');
}
return false;
}
Obviously, a lot more can be done with this, like handling error codes, formatting user errors, sending messages off to your mobile, etc. I check for an array in $msg and list multiple errors through a templater for example.
This way you can handle unrecoverable errors, or just spit general errors back to the user:
PHP Code:
if(!database_exists()) s_error("Our database has been stolen!",true,1,true);
"A proof is a proof. What kind of a proof? It's a proof. A proof is a proof. And when you have a good proof, it's because it's proven." -- Jean Chrétien
I sometimes put a die() statement after a debug statement, that way you often won't end up with a page of HTML masking your debug lines.
Test your code in bitesize pieces, that is don't write an entire script and then debug it, write a function or a method and then debug it with dummy data.
function s_error($msg='Undefined Error', $kill=false, $priority=3, $log=false)
{
//one time call to a used everytime function
if ($log === true)
log_error($msg,$priority);
switch($priority)
{
case 1: // Alert the troops
//assuming this log_error was supposed to be identical to the other 2 and removing it also
sound_the_alarms($msg);
die('We might not be back for a bit.');
case 2: // Unrecoverable system error
die('System Error: ' . $msg);
case 3: // User / general error
echo "Sorry, an error occurred: " . $msg;
break;
default: // Or however else you want to handle this by default
die('Unspecified error');
}
return false;
}
Obviously, a lot more can be done with this, like handling error codes, formatting user errors, sending messages off to your mobile, etc. I check for an array in $msg and list multiple errors through a templater for example.
This way you can handle unrecoverable errors, or just spit general errors back to the user:
PHP Code:
if(!database_exists()) s_error("Our database has been stolen!",true,1,true);
It's hot needles in the eye time when I see "You put addslashes when you put data into a database and stripslashes when you take it out"
It's become like an old wives' tale of sql programming.
Not using [PHP] tags makes the baby jesus cry.
The help of an enthusiastic idiot is worse than the sabotage of an expert.
Don't be a PhPenis - RTFM - still stuck? Then go DAFT (Do AFekkin Tutorial)
If your conditional statement isn't working properly, and it's testing for equivalence, check that you've got two equals signs.
I'm just going to expand on this and share a tip that would help if you've been using literals and constants on the right side of an 'if' expression. Example code:
PHP Code:
$value = 2;
if ($value = 1)
echo 'one'; // This gets displayed
elseif ($value = 2)
echo 'two';
The equal comparison operator in PHP requires two equal signs (==) and not just one (=). One equal sign is an assignment operator. In the example code, the '1' was assigned to the $value variable at the first 'if' expression, and this made the expression evaluate to TRUE; causing the echo 'one' to be executed and displayed. With this type of code example, PHP produces no errors (when there's a variable name to the left of the equal sign). This makes debugging this kind of problem more difficult and potentially time consuming. It's not always very apparent.
Here's a tip to avoid this problem in the future. Get in the habit of coding the 'if' expression with the literal value or constant first or to the left of the equal sign, like this:
PHP Code:
$value = 2;
if (1 == $value)
echo 'one';
elseif (2 == $value)
echo 'two'; // This gets displayed
That way if you happen to make a mistake and put just one equal sign again, then PHP will give you a parse error. The code of '1 = $value' is invalid because PHP can't assign the contents of $value to '1' (a literal; it must be a variable). This could potentially save you lots of time in testing/debugging because you get an error alert.
Originally Posted by barand
Check variable contents
Use something like this to check you received what you expected to receive
When working with databases, use a database object - And all queries are sent through it, eg
$db->query("SELECT * FROM $table $where");
Then, while your developing your site, you can have the db object always echo out the query being used (and runtime information that query took) to help in development.
Another tip, 'return early'.
If you can stop processing another line of code by doing a simple check, then do that. For example:
Reply With Quote
Originally Posted by GilesGuthrie
Bookmarks