Let's say you're maintaining code that uses PHP's native trigger_error() function to log error information. Let's also say that you're in the process of using PHPUnit to write unit tests for that code. If you refer to the PHPUnit manual, there's a section that deals with testing for error condition. [...] However, depending on what your code looks like, it's possible that you'll run into a problem with PHPUnit's approach to this. This article will detail what this problem is, how it impacts your ability to test your code, and how to go about solving it.

He points out that, since errors and exceptions handle differently, you have to work with them differently in your tests. PHPUnit has a feature that automatically turns errors into a specific type of exception when they're thrown and how, by using a simple custom error handler, you can more correctly tests error vs exception.

Much like many other developers, I like to live on the bleeding edge, learning new language features, using the latest tools so naturally one of the things I wanted to see in Windows Azure Web Sites is support for PHP 5.4. I'm pleased to be telling you today in this post that support for Bring-Your-Own-Runtime is now available in Windows Azure Web Sites. Out of the box, Windows Azure Web Sites supports PHP 5.3 as you can see from the snapshot of the portal below. In this article I'll explain how to enable PHP 5.4 in Windows Azure Web Sites.

You'll need to set up and configure an Azure instance to work with (if you don't already have one) and navigate to its management Dashboard once complete. You can then setup a handler mapping that points to an uploaded version of the PHP Windows binary for 5.4 on your document root. Then all that's left is to upload (via FTP or git) this executable and you'll be all set.

This tutorial will show you how to use Amazon DynamoDB as a storage facility for PHP sessions. This method becomes very useful when your applications take advantage of the Elastic Load Balancing and Autoscaling services. You will need Amazon AWS account enabled to use EC2, Elastic Load Balancer and DynamoDB as a prerequisite to play along the tutorial.

He starts with a description of what the elastic load balancing service is and how it autoscales. He shows how, based on this demo application, to use a custom PHP session handler that implements the Amazon SDK libraries to hook into the DynamoDB service. Also included are screenshots (and the steps that go with them) to configure the service itself.

Today I ran into a problem where my PHP Application would throw this fatal error: "Fatal error: Exception thrown without a stack frame in Unknown on line 0". Which is so much fun, because it doesn't have a line number, so I had no direction as to what exactly was causing the problem.

He found a blog post that helped him track down the issue that, as it turns out, with serializing objects into the session and an error in the __sleep method.

So far we've covered parsing requests to determine exactly what the user is asking for, and also looked at routing to a controller to obtain the data or perform the action required. This post gives examples of how to return the data to the client in a good way.

She advocates using output handlers instead of the usual views you'd think of in a typical MVCish sort of application. The difference here is that there's not a lot of extra overhead to produce the results - it's literally an output directly from a class extending the base view (including the correct headers). She also briefly mentions the inclusion of JSONP functionality, allowing you to specify a local callback to execute when the request is returned. A few other "nice to haves" are also mentioned like the number of results returned and pagination support.

Sessions are a tool which helps the web programmer overcome the stateless nature of the internet. You can use them to build shopping carts, monitor visits to a website, and even track how a user navigates through your application. PHP's default session handling behavior can provide all you need in most cases, but there may be times when you want to expand the functionality and store session data differently. This article will show you how the default functionality works and then goes on to show you how override it to provide a custom solution.

They introduce how sessions are stored normally (based on the save path) and what the serialized contents of it would look like. They show you how to take this, normally stored on the local file system, and change it to be written to a "session" table in a MySQL database (via PDO). It includes reading, writing, updating and some garbage collection to clean out old values from the table.

Errors are the most common event a developer faces when programming. [...] To help reduce the number of errors in your code, and to mitigate their effects, proper error handling is essential in your web application. This article is a crash course in PHP error handling. You'll learn about PHP's built-in error reporting levels, and how to handle errors with custom error handlers and exception handling.

She starts with the different error reporting levels PHP offers, everything from the lightweight E_NOTICE out to E_ALL|E_STRICT. With this as a reference, she shows how to create a custom error handler (using set_error_handler). Also included is a look at exceptions and some of the more detailed information that comes with them - line numbers, messages, file the error was thrown from, etc.

Shared hosting are cheap, but normally they don't allow us the use some kind of features. For example we cannot see the error log. That's a problem when we need to see what happens within our application. Normally I work with my own servers, and I have got full access to error logs. But if we cannot see the error log and the server is configured with display errors = off in php.ini (typical configuration in shared hosting), we have a problem.

His solution involves an "error sniffer" script that captures the issues in a script and echoes them out at the end. In his ErrorSniffer he sets up a custom error, exception and shutdown handler to grab the problems and capture them for later use - including echoing them out to the user if desired.

If you've ever built a Zend Framework MVC app which makes AJAX calls, you may have noticed that if an error occurs, you'll get a chunk of JSON followed by the HTML for the error page. If you've built a layout, you'll get all of that back to. This is fine if your users hit the page in the browser but it can cause problems with your JavaScript being able to correctly decode your JSON.

The fix is pretty simple, though, and only requires that you add the error handling action to the Ajax context to force it to drop the layout and any other HTML that might come along with the view. He includes a bit more code to have the error handler include the exceptions and pass them out to be included in the JSON response.

We use sessions when we want to preserve certain data across subsequent accesses. PHP allows us to use different handlers when we're using sessions. The default one is filesystem, but we can change it with session.save_handler in the php.ini. session.save_handler defines the name of the handler which is used for storing and retrieving data associated with a session. We also can create our own handler to manage sessions. In this post we're going to create a custom handler to store sessions in a node.js service.

He includes the full code you'll need (also here on github) to make a custom session handling class on the PHP side and some simple unit tests done on the Node.js side to ensure for proper handling and garbage collection.