Court Ewing has a new post to his blog describing some of the most common cryptic errors that you might come across in your day-to-day development.

If you've been programming for awhile, then you've probably experienced your fair share of cryptic error messages. It's understandable that building in detailed error messages that are clear to even novice developers is not always a high priority for programming languages when there are so many other features to create and issues to address. The PHP language has decent error messages, but it is by no means an exception to this rule.

The three errors he covers are probably familiar to anyone that's been working with PHP for any length of time:

• Fatal error: Parse error: syntax error, unexpected T_PAAMAYIM_NEKUDOTAYIM
• Fatal error: Can't use function return value in write context
• Fatal error: Exception thrown without a stack frame in Unknown on line 0

Rob Allen has a new post to his blog today introducing you to the ZendEventManager component of the Zend Framework v2, a key part of how this latest version of the framework does its job.

Zend Framework 2's EventManager is a key component of the framework which is used for the core MVC system. The EventManager allows a class to publish events that other objects can listen for and then act when the event occurs. The convention within Zend Framework 2 is that any class that triggers events composing its own EventManager.

He starts with some terminology to get everyone on the same page (listener, event, EventManager) and includes an example of its use in setting up a "PhotoMapper" object showing how to trigger events in the "findById" method. He shows how to listen for a specific event (in his case, a "pre-execute" on the "findById" method) and a method for "short circuiting" the listener based on the response from the "trigger" call. He also touches on the "SharedEventManager" that can be used to add an event across all of your application at the same time.

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.

On PHPMaster.com today there's a new tutorial from Lorna Mitchell introducing you to using Analog for error logging in a MongoDb connection. Because of the way the tool (Analog) is designed, it could be used anywhere - she just uses the MongoDB connection as an example because it integrates easily and efficiently.

MongoDB is an excellent fit for logging (and of course other things as well) for many reasons. For one, it is very VERY fast for writing data. It can perform writes asynchronously; your application wont hang because your logging routines are blocked. This allows you to centralize your logs which makes it easier to querying against them to find issues. Also, its query interface is easy to work with and is very flexible. You can query against any of the field names or perform aggregate functions either with map/reduce or MongoDB 2.2's upcoming aggregation framework.

This article will show how you can use existing code to add a logging library to your code and log errors to MongoDB. You'll also see how to query MongoDB from the command line and how to filter those queries to find the information you are interested in.

Analog makes it simple to log information in an easy to use, self-contained, extensible kind of way, offering writers for multiple output formats including: files, the FirePHP plugin output, email, POSTing to another machine and sending to a syslog daemon. She also mentions the different logging levels the tool makes available and how to filter down your logging results based on them (searched by "equal to", "greater than" and grouped by level).

New on PHPBuilder.com today Leidago Noabeb gives you a pretty comprehensive overview of error handling in PHP - everything from the types of errors to how to control which are output in which environments.

In this article we will be looking at how to handle errors in PHP. Errors are an inevitable part of software development, and accordingly, we will be looking at the various error types and demonstrating how to handle them. If you intend to run any of the sample scripts in this article, please make sure that display errors is turned on in your PHP initialization document (php.ini).

The article talks about the types of errors PHP uses (syntactical, runtime and logical) and shows how to handle some of the most common issues with them. It also talks about the different error reporting levels (ex. E_ALL, E_WARNING, E_STRICT) and includes the code for a simple error handler class that switches off and handles each type differently.

Following up on their previous look at the component architecture of the Yii framework, PHPMaster has posted this new tutorial showing how the framework allows you to do some event-based programming.

An application event is something that occurs which might be of interest to other bits of code. A standard event in most GUI applications would be a "click" event, but the sky's the limit and what events you define is really up to you. [...] The details can be provided by application-specific modules allowing you to keep individual requirements separate from your reusable code. Events allow you to attach a potentially unlimited amount of functionality without changing your core modules and components.

In his example, he shows how to create an event handler that is triggered when the user registers on the site. This event (CEvent) is then registered with the system and is attached via a call in the controller's "init" method.

In this new post to his blog Nikita Popov looks at an update that might have gotten lost in the shuffle of new features coming in PHP 5.4 - some updates to htmlspecialchars.

One set of changes that I think is particularly important was largely overlooked: For PHP 5.4 cataphract (Artefacto on StackOverflow) heroically rewrote large parts of htmlspecialchars thus fixing various quirks and adding some really nice new features. Here a quick summary of the most important changes: UTF-8 as the default charset, improved error handling (ENT_SUBSTITUTE) and Doctype handling (ENT_HTML401,...).

He goes into each of these three main features in a bit more detail, providing code to illustrate the improved error handling and the new flags for Doctype handling (covering HTML 4.01, HTML 5, XML 1 and XHTML).

Brian Moon has a reminder about date handling in PHP - days are not always 86400 seconds long, sometimes there's "leap seconds" included too. Thankfully, there's easy ways around it:

The problem with this is that it assume that there are only 86400 seconds in every day. There are in fact not. On days when the clocks change for daylight savings time, there are either 1 hour more than that or 1 hour less than that. In addition, there are also leap seconds put into our time system to keep us in line with the sun. There is one this year, 2012, on June 30th in fact. Since they don't happen with the regularity that daylight savings time does, it may be easy to forget those. Luckily, for this problem, the solution is the same.

His first solution involves letting strtotime do the work for him, internally calculating the leap seconds or any other issue that might come up. As an alternate solution, he also mentions "doing your math at noon" - this gives you enough leeway to make the offset leap seconds could cause a much smaller risk.

In this quick new post to his blog Mark Story talks about two new errors he ran across when upgrading his installation to PHP 5.4, both showing up under E_ALL.

I've been running the PHP5.4 RC builds for the last few months, and there are some interesting changes in the upcoming PHP release. On top of all the great new features coming in PHP5.4. After updating to PHP5.4-RC4, a few things that used to not trigger errors and silently do the wrong thing, now trigger notices or warnings.

The two he mentions deal with a new warning on illegal string offsets and the other about string offsets ("Notice: String offset cast occurred"). You can find out about more changes in the PHP 5.4 series in the various Changelogs for each Release Candidate and beta release.

Lorna Mitchell has a quick new post showing one way to handle SQL errors in PDO that could pop up because of badly written/generated SQL statements.

I love PHP's PDO (PHP Data Objects) extension; it gives a consistent, object-oriented interface to handling all kinds of relational database backends. One thing that annoys me is that the MySQL driver for PDO defaults to a silent error mode which can make SQL errors tricky to spot!

In her two code snippets she shows a failing PDO request (that fails silently) and a method for catching this issue - checking the result of the "errorCode" method to see if it equals "0" (zero). If there were errors, you can use the "errorInfo" function to get to them. This will return the SQL error code, the driver-specific error code and a driver-specific error message.