Handy PHP Debugging Tools
I'm sure most folks who read this blog are already set in their ways of debugging things. And many probably already have a few custom built methods they use to look at raw data on the fly. However for those few who might be in need or are possibly looking for another approach this post is for you 
.
I used to rely solely on a step through debugger to help me debug code, and don't get me wrong stepping through code is a great way to see what the heck is going on (especially in code you are unfamiliar with and was written by monkeys), however for the last year or so I've been learning new techniques and tricks for getting my raw data visible without having to step through the code.
My all time favorite method is
echo "<pre>".print_r($array, true)."<pre>"; |
but there are times that is not good enough. like when you are trying to see data run in shell_exec() or when the page changes before you can see the echo. So to combat this I've written a method that drills through an array or an object and spits the data out in a file in a format similar to the aforementioned. I call it pre()
observe
function pre($array, $mode = 'w', $indent = "\r\n") { if(is_array($array) || is_object($array)) { $filename = 'C:\logs\dnate_pre.log'; $handle = fopen($filename, $mode); fwrite($handle, getArrayKeysAndValues($array, $indent)); fclose($handle); } else { writeToFile($array, $indent); } } |
and if you're wondering what the getArrayKeysAndValues() method does, here it is.
function getArrayKeysAndValues($array, $indent = "\r\n\t") { $txt = ''; if( is_object($array) ) { $array = get_object_vars($array); } if(is_array($array)) { $txt .= " => Array ("; foreach($array as $k => $v) { $txt .= $indent."\t[".$k."]"; if( is_array($v) || is_object($v) ) { $txt .= getArrayKeysAndValues($v, $indent."\t"); } else { $txt .= " => ".$v; } } $txt .= $indent.")"; } return $txt; } |
Occasionally I've run into a limit of how many times getArrayKeysAndValues() can call itself (100) so in cases like that I've also got a method I call kill() that kills the script and spits the output out on the browser. Not very subtle but gets the job done.
Obviously you'll have to have the log files in the proper directory on your machine. Then just include the file and call the desired method.
The rest are in the download, feel free to offer suggestions or comments.
Print This Post
Handy PHP trick I learned today.
Nice to see the Dev blog is still here, and that I can remember my login. Here is a useful debugging trick I learned for PHP, hopefully it's not in one of Phil's link posts.
echo '<pre>'.print_r($app,true).'</pre>';
this bad boy will give you all of the values of an array, variable etc.
more to come soon.
Print This Post
httpSpy for Firefox!
This morning I stumbled onto a real treat for those developers that are using Firefox. Backstory: A while ago Ninja had suggested that we use a little program called "httpSpy" for debuging the header information that was being served/requested by our server/browser (very useful to find obscured links, what items are really being loaded on a page, and what connections are being secured). The problem is that while the program is awesome (and extremely hard to find as there are 3 or 4 variants on a google search that are all different), it only works with IE. Naturally, this is undoubtedly causing a shudder and a distinct feeling of betrayal to surge up from the depths of your soul . The time of IE only debugging is at an end... Introducing "Live HTTP headers", a fantastic little tool that pops up in a different window that will show you your requests and let you resend them ( with some modifications) and logs everything being passed to and from the server/browser. While I haven't really played with it for more than a few minutes, it seems like a good tool, and I'd recommend throwing it in the arsenal.
Live HTTP headers - can be downloaded here (link goes to the mozilla add-on site, as I did not grab the xpi file). It also works with FFox3RC1 
.
Print This Post
The joys of Try Catch (in a jsp)
This post is brought about after having Ninja come over and look at my code and making me realize that while what I was doing was good, I had not used a try catch and as such would never find exactly why my code was generating over 1500 lines of errors in my server log (ouch). Here is the way of Scriptlet (aka ninjascript) Try Catch-ery.
<% try { %>; <%-- code goes here --%>; <% } catch (Exception e) { e.printStackTrace(); Thread.sleep(20000); } %>; |
You can further mod this to make it possibly more helpful by adding/replacing the last line so you end up with something like:
<% try { %> <%-- Code goes here --%> <% } catch (Exception e) { System.out.println("Exception caught in NameOf.jsp"); System.out.println(e.toString()); e.printStackTrace(); } %> |
Now for those people who are purists and understand that scriptlets really are not up to par, and that they are ugly and screw things up and are not elegant in the least, there is another way to Try Catch on your JSP. Simply use a JSTL Try Catch. Here I'll set up an example:
<c:catch var ="catchException"> <wcbase:useBean id="category" classname="com.ibm.commerce.catalog.beans.CategoryDataBean" > <c:set value="${WCParam.parent_category_rn}" target="${category}" property="categoryId" /> </wcbase:useBean> </c:catch> <c:if test = "${catchException!=null}"> The exception is : ${catchException}<br /><br/> There is an exception: ${catchException.message}<br/> </c:if> |
We set up a variable (catchException) and then what we want to do inside that c:catch. So we are trying to instantiate this bean and we want to make sure it doesn't throw an error (which as part of the joys of websphere if that bean throws an error your page will fail and you'll either get a portion of your page with nothing else, or you'll get a series of dreaded CMNxxxx errors). Right after the c:catch block we set up a c:if with to test value of ${catchException, if it's not empty, then an error was thrown and we should kick out what the error is so that we can fix it (without digging through 1500 lines of error-logged code).
Print This Post
Weekly Training – Debugging
It's time to learn how to get the bugs out. This week we covered basic debugging (from starting the server) to using some external tools (such as the fantastic Firebug plug-in). For the full show you can check the audio clip at the end (I'll post it when I'm done 'cleaning' it).
Highlights:
- Rational debugging mode
- Firebug (for both CSS editing and javascript debugging)
- Drew's fantastic commentary as nothing works the way he intends (for the first 20-ish minutes)
- My extremely long pause... that I think I may still be on.
On a side note, there are two other tools that are very helpful when trying to debug or develop on IE, Safari, Linux browsers, etc. They are XRAY and Aardvark, and both are bookmarklets (meaning you bookmark the javascript itself and run it when you need it, similar to a bookmark).
XRAY can be found here http://www.westciv.com/xray/.
Aardvark can be found here http://karmatics.com/aardvark/bookmarklet.html.
Audio clip will be here when I'm done editing it... UPDATE: Or it won't, looks like my sansa destroyed the file, I mean it's still there, just not in a format that any program can read... I may still play with this, but I'm thinking it's a lost cause... sorry 
Print This Post