Recently I made some test in AMFPHP sending an retrieving ByteArray to be stored in a mysql blob field. But suddenly I encounter a problem when I was trying to return an array of ByteArrays and I could not find out the reason flash continued to show me [an] error.

He includes the offending code on both the PHP and ActionScript side and his ultimate solution - a problem with AMFPHP's serializer. He's even made a patch file if you're seeing the same issue and want to bring your install up to date.

This post is about the consistency of frameworks. Consistency is key to a low learning curve. [...] Yesterday, my brother asked me how he could capture 404 errors in Cognifty, as he was building an app that relied on dealing with random URL patterns. [...] After talking for a bit, we decided that handing off the request to a standard service (or controller) was the best way to handle this type of "error". He started searching to see if other frameworks had a consistent, or at least documented, way of dealing with missing controllers.

In his research he found one framework - the Zend Framework - that handed them by default as an error and passed them off to that handler. Mark notes that, depending on your frame of reference, this may or may not be considered a true error.

His Cognifty framework handles things a bit differently. It allows you to change the presentation handler to redirect to another url if an error like a 404 is thrown - a technically "more correct" way of handling things.

Everyday the forums see probably hundreds of topics posted where the problem is a fairly simple error. [...] As a beginner, it can be difficult to find and solve these errors. By tackling each of these in turn, I hope to teach you some methods of finding and solving them.

They look at the different sorts of errors - syntax errors, fatal errors, warnings, notices - as well as some of the ones a bit harder to track down like database problems and logical errors.

I just recently installed the this latest version of Wordpress (2.5.1) and quickly found it hanging (while trying to load a page) for as long as 40-50 seconds! I then proceeded to isolate the potential causes (database, custom fields, custom theme) and have since found out that something stinks in 2.5.1's core.

He details some of the steps he took to try to track down the bug - installing on another server, searching the web for others with the same issue. His suggestion?

Before you upgrade your old working installation of Wordpress, I would suggest that you test 2.5.1 in some other directory just to be sure it works with your server.

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.