?>

How I debug PHP errors and issues

I spend a lot of time in various IRC channels answering questions and helping out, and one recurring theme that pops up again and again is people not knowing what to do when things go wrong. Whether it be a simple error or a logical mixup, people often lack the tools or processes to figure things out. So I thought I would share how I approach errors and problems. I like to think of error and debugging techniques as layers or levels of defense. I go through each layer until I reach the end.

Errors and error messages

Errors happen but the most important thing to do is to read them. Often errors have lots of valuable information, such as the type of error, a message, and what line & file the error came from. So reading and sometimes re-reading error messages is the first step to solving errors. Suppressing or otherwise hiding errors, does not fix them. It just delays the inevitable implosion of garbage code.

Sometimes re-reading errors doesn’t make them any clearer, at this point I turn to Uncle G and put in the generic parts of my error and see what comes back, usually I get something good and am able to resolve the issue.

Sprinkle some output

When reading an error message isn’t enough the next level of error defense is some dumps. I’m a huge fan of debug() and var_dump() These functions are invaluable for finding out what’s going on inside your code. Often sprinkling some debug() here and there will give me enough information to get the issue solved.

Isolate the problem in a test case

If debug() doesn’t save me, I start writing more test cases. I normally write a fair number of test cases while writing code. But when faced with an extra gnarly problem I write even more test cases. Using test cases helps me isolate the issue and narrow down the where and how the issue is being caused. Test cases have the added bonus of living beyond my current session, and helping to prevent the same problem later. If I can’t reproduce the issue in a test case, I’m either looking in the wrong place or there is some extra funky junk in my code.

Break out the GDBp and other big guns

When faced with an nasty problem that I can’t solve with test cases, I turn to step debugging with xDebug and MacGDBp, If you are an eclipse user there is a GDBp client built in, there are GDBp clients for every platform as well. If my issue involves remote requests or Javascript, I crack open Firebug and or Charles. In either case I set some breakpoints where I think the issue is and step through the code one line at a time looking at the variables and ensuring they contain what I think they should, and that the program flow is correct.

If an involved session of debugging doesn’t get the issue fixed, its time for coffee/water. I find when all my tools and techniques fail me, its usually me not seeing the trees in the forest. A five minute respite often gives me the break I need to come back with fresh eyes and see the problem staring me in the face.

So those are the common steps I take when I have an error or issue in my code, what are yours?

Comments

Great idea for an article Mark. Here’s a few points to add to this handy reference:

If there are no error messages for whatever reason (ie. you are experiencing the white screen of death), don’t forget to look at the Apache error logs.

The Apache access log can be handy for mod_rewrite issues.

Also, when debugging session-related issues, such as issues with AuthComponent’s auto-redirect, a debug($session->read()) in your layout page can come in rather handy.

deizel. on 6/25/09

I’d think that DebugKit would be in this list as well, I don’t know how I’d manage without it, it rocks. That together with FirePHP is a really good start as well.

Oscar Carlsson on 6/30/09

Oscar: Yeah shortly after posting the article I remembered there were a few more things I like to use, one is DebugKit The other is creating stack traces. I find stack traces invaluable for figuring out where and how methods are being called. I normally use debug(Debugger::trace()); for generating simple stack traces.

mark story on 6/30/09

I think I’ll point a lot of people to this article, from IRC.

This will be a great resource.

TehTreag on 7/2/09

Hello – im all new to this Cake story, but one thing is for sure, you dont have that many bugs with Cake, thats what I noticed, you have a better view of the Project, here is a cake baked with Cake ha http://www.droparecipe.com/recipes/view/chocolate-cake

Baker on 7/8/09

a question are there any sites where you can see different sites made by cake

Baker on 7/8/09

Great article as always thanks Mark.

I have been using spectator http://code.google.com/p/spectator/ – but I will checkout Charles

@Baker http://book.cakephp.org/view/510/Sites-in-the-wild

ps There are some odd css glitches with lists :)

sam on 7/8/09

Nice post, thank you very much, i do personally commit my self into this sequence when i face a problem with my code but i would like to assure “as the first comment has already mentioned” that the log files are also in the same level of importance, sometimes only looking at the error log may point you directly into the solution, i usually use the tail command together with -f option to try reproducing the hard catching issues, error and access logs are also very important in any debugging technique in the development of any project.

Ma'moon Al-Akash on 9/8/09

var_dump and Uncle G are my best bets when error come. I usually debug my code after doing those things.

Thorpe on 11/17/09

Hello Dear.
It’s a must appreciable attempt to write such an article. It helps us to build a nice one.

Zamshed Farhan on 1/14/10

TejmlaKed on 1/1/12

Для того, чтобы отдалить наступление оргазма, тем самым, усилив его, вы можете прекращать мастурбацию на несколько секунд. Мастурбировать в душе может оказаться также очень приятным способом, вода сама все сделает за вас, вам можно просто расслабиться, пока струйки воды ласкают ваши эрогенные зоны.

http://www.chudomart.ru/ http://fast-people.ru/

Anumaneitaka on 3/10/14

Comments are not open at this time.