The most basic debugging technique

If you are experiencing a problem with your script, the most time-honoured way to figure out what is going on is to sprinkle your code with lots of print statements. This is a technique that few people will admit they use, but I can assure you it is widespread - and not just in the PHP programming world! Consider this following script:

<?php
    $foo = "bar";
    $wombat = somefunc($foo);
    print "After somefunc()\n";
    $wombat2 = somefun2($wombat);
    print "After somefunc2()\n";
?>

If we found that somefunc2() was causing a problem that caused PHP to silently exit the script, we would see the output "After somefunc() ", but not "After somefunc2() ", which points clearly to the problem function.

This method has benefits - it is easy to use, and will generally find the problem through trial and error. The downsides are clear, though - you need to edit your script quite heavily to make use of the print statements, then you need to re-edit it once you have found the problem to take the print statements back out. Furthermore, the technique is a relatively slow way of finding problems, as you literally need to keep placing more and more print statements until you find the problem.

Many people combine this with use of var_dump() to inspect variable contents at various points in their script. If you do not have a good debugger, this is the only way you will find out what your variables contain, however you may find it easier to use the function debug_zval_dump(), which takes one parameter (the variable to dump information about), and prints out even more detailed information than var_dump(). The key advantage of debug_zval_dump() is that it prints out the refcount value of variables sent into it - that is, how many times each variable is being used. If you have trouble getting references to work, using debug_zval_dump() is a smart move.

Copyright ©2015 Paul Hudson. Follow me: @twostraws.