Justin Carmony has a recent post to his blog about a problem he came across where his exception was being thrown with a line number of zero - cause for some investigation.

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.

Lorna Mitchell is back with another post in her "Building a RESTful PHP Server" series today with this new post showing how to work with output handlers (her focus is on JSON).

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.

On PHPMaster.com today there's a new post showing you how to write custom session handlers - in their case, a database-based option that can span across multiple servers/services.

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.

On PHPMaster.com today there's a new tutorial from Sneha Heda looking at error handling in PHP - the types of errors that can come up, how to throw your own and how to catch them appropriately.

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.

Gonzalo Ayuso has posted a handy tip to his blog today about showing errors even with "display_errors" being off in your application (could be helpful in debugging those difficult problems).

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.

David Stockton has a new tutorial posted to his blog - a technique he's found useful in his Zend Framework application to make the ErrorController work with Ajax calls to reduce the message you get back to just a JSON response.

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.

Gonzalo Ayuso has an interesting new post today looking at how to go cross-technology in your application and store your PHP sessions in a basic Node.js instance.

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.

In a new post to his blog today Chris Shiflett takes a look at something a lot of PHP developers take for granted, the language's session handling, and some things you can do to help debug them when things go wrong.

For many PHP developers, calling session_start() and using $_SESSION for stuff you want to persist from page to page is all there is to know about sessions. This is understandable, because PHP's native session support is so simple and reliable. But, what if something goes wrong?

He points to two older articles he's written about some more advanced session handling and includes sample code acting as a walk-through for locating your problem spot. He focuses in on the read() handler method and shows how to debug the data flowing in and out (and some of the information he commonly logs from it).

In a new post to his blog Kevin Schroeder shares an encrypted session handler he's created to keep sensitive information away from prying eyes (since session data is usually plain text). The result ended up in a component easily used in a Zend Framework application.

A little while ago I had come upon the problem of having to store sensitive data in a user session. The solution that I (and several others came upon) was creating a mechanism for storing encrypted data in a session. But what we wanted to do was build something that didn't have a single point of failure. We also wanted to build something portable. What we built was a simple Zend Framework session handler for storing sensitive data.

The class - App_Session_Secure_Namespace - extends the standard Zend namespace and uses the mcrypt functionality to encrypt (and decrypt the session data). The setup uses a cookie for the initialization vector (domain based, naturally) making it very difficult for someone to access the encrypted session information outside of the application.

Corey Ballou has posted a MongoDB-based session handler to his site with a new update back on July 1st.

MongoSession is a PHP implementation of a MongoDB session wrapper. This class was built as a drop-in for easily switching to handling sessions using Mongo. It's a great replacement to memcache(d) for VPS servers where you risk memory being reshuffled in the pool and taking performance hits.

You can grab the latest version of the source from the github repository for the project or just copy and paste the source directly from this page on his site. A usage example is also included.