While debuggers exists, there isn't much of a tradition for using them in PHP. People have largely come to rely on injecting debugging code directly into the program, for inspecting program scope.

Tools mentioned include traceers and error handlers (like XDebug), some debugging parts of the popular PHP frameworks and the set of *cachegrind tools to help you parse the output of XDebug for profiling your application.

If you think that the maxlength parameter in the documentation of oci_bind_by_name is optional, see this example and think again.

His sample code gave him a "can bind a LONG value only for insert into a LONG column..." error from his Oracle database. His fix was to add that length parameter (his max column length) and all was well. One of his comments (from cj) helps to explain things a bit more:

It makes senses that a length would be required because when the oci_bind_by_name() call is made, there is no data in $$key (a.k.a. $a, $b or $c). Without a length passed, PHP tells the DB to expect a single byte string.

While I would personally prefer an exception to be thrown in the first place, it is pretty easy to convert errors to exceptions in PHP.

His example is pretty simple - you set a custom error handler in your script that pulls in the error information and tosses an exception based on the error number the handler is given. Then you can use the try/catch method to see if your script has tossed an exception of the fatal error type. Nice simple solution to handle an interesting little problem.

In this third tutorial of the series, I'm going to show you how to incorporate a brand new error checking module into the file uploading PHP script created in the last article.

They show the basic method - uploading with no error checking - before showing how much help adding in an error checking component to watch for things like files that are too large, invalid file choices and problems writing the file on the server side.

As many of you know, this time of the year is usually the PHP Quebec conference and many php internals and international speakers fly to Montreal to speak. [...] This morning (2008/13/03) I saw Lukas on IRC and we said "Hey let's meet around 1pm to discuss about the PHP TestFest"

He met Lukas at the hotel, in the lounge of the hotel, not attending any of the talks. As he sits there talking to the others, a PHP Quebec staff member walks out and hands him a bill (for around 450 CAD) for attending the conference. After a little checking - both with fellow user group members and with the hotel staff as to the validity of this behavior, he could only assume that it was some "money driven" attempt on the PHP Quebec conference's side to get what they could.

Be sure to check out the comments for some other views from the community.

Despite the proliferation of debugging tools, especially real-time debuggers, "debugging by print statement" remains the most common form of debugging in most programming languages.

An example of its use is included by way of a debug() function that returns the message it a bit friendlier format.

Traditionally in a CakePHP application, to do static pages you have two options: use the built-in Pages controller or set up an empty action in a controller.

Feeling that neither of these two options met how he wanted things to work, Jonathan (and Nate Abele) developed a class that extends the error handler in the CakePHP framework to handle "missing" actions and controllers. This means that, if an unknown controller/action combo is called, this script will check in its correct location (in the structure of the site) and try to find it to render it.

This article is the first installment of a five-part series of articles covering xdebug, a free and open source swiss army knife tool for PHP developers. xdebug is a PHP extension created by Derick Rethans, one of the PHP core developers. This week, we will show you how to install xdebug and introduce you to some of the basic features. In the subsequent parts of this article series, we will have a closer look at one of xdebug's main features, namely tracing, profiling, debugging, and code coverage.

In this first installment, he looks at installing the software (both on a unix-based system and on a Windows box) and how to turn it on to work with your web server. He also mentions some of the error output options including the "new and improved" var_dump call and the stack trace method to help you locate exactly where in the code the error's hidden.