As part of a project to migrate the PHP code at work from PHP 5.2 to PHP 5.4, I'm using our extensive test suite to look for instances where something that changed between the versions of PHP that we are using has caused some unexpected behaviour. In one of our code bases, I found some tests that are exhibiting a test smell through their use of a try / catch block in the test itself.

He includes a (contrived) example showing the use of an exception in a unit test to run an assertion in the "catch" for the test to pass. He points out that this particular check is being done to see if the user input is valid...and that it's a bad way to enforce it using exceptions. He also suggests that if you have an "if" situation, don't use one test with logic in it, write two tests. He mentions a disenting opinion but notes that a failing test is a failing test, regardless of what caused the failure.

I recently had a problem with a ZF2 based website where users were reporting seeing the error page displayed, but I couldn't reproduce in testing. To find this problem I decided to log every exception to a file so I could then go back and work out what was happening. In a standard ZF2 application, the easiest way to do this is to add a listener to the 'dispatch.error' event and log using ZendLog.

He uses an event listener to attach a service that contains a "logException" method. This method uses the ZendLog component to write out the error message to a local log file including a backtrace of where the issue occurred.

Slim is a lightweight framework that packs a lot of punch for its tiny footprint. It has an incredible routing system, and offers a solid base to work from without getting in your way. Let me show you! But that's not to say that Slim doesn't has some issues; it's one-file setup becomes cluttered as your application grows. In this article, we'll review how to structure a Slim application to not only sustain, but improve its functionality and keep things neat and systematic.

He starts with an example of "vanilla Slim" and looks some at what's happening behind the scenes in the routing engine. They then give you a step by step installation and usage guide including updating the router to use class files. An example controller is included as well as some basic error handling using a Twig template for use across the application.

I've come to known a bit about spawning and monitoring new processes from PHP code, while working at Onebip and trying to contribute to Paratest. Here's what you need to know if you think exec() or executing everything in a single .php script is always enough.

He starts with a look at the differences between using things like exec and streams for handling the spawning of other processes. He shows how you have more control when you go with the streams option and process handling with the "proc_*" methods. He also touches on some other things to think about like stream blocking, sleeping and dealing with multiple execution streams (and switching between them).

In my last post, I covered some background on REST and the Richardson Maturity Model, and some emerging standards around hypermedia APIs in JSON; in particular, I outlined aspects of Hypermedia Application Language (HAL), and how it can be used to define a generic structure for JSON resources. In this post, I cover an aspect of RESTful APIs that's often overlooked: reporting problems.

He starts with some of the things around error handling and APIs that bother him and why just returning a status code representing an error isn't enough. He suggests two possible solutions to this issue - two messaging formats, API-Problem and vnd.error. He gives brief summaries of each and includes example output to give them some context.

Exception handling is available in PHP since version 5. It allows you to have a more fine-grained control over code when things go wrong ie, when exceptions occur. But since PHP 5.5, exception handling has finally evolved into what it should have been from the beginning: the "finally" part has been implemented.

He includes a basic example showing how a certain part is always executed, regardless of if the exception is thrown or not. He also shows how a "chained catch" would work to catch multiple kinds of exceptions and when the "finally" is run as it relates to the "trickle down" handling of exceptions. He then gets a little more complex and introduces "return" into the mix. Of special note, even if you return, the "finally" will still get called.

Recently I tweeted as a #linktuesday link the 10 Worst API Practices post from ProgrammableWeb. Today, in search of some concrete examples of APIs implementing unhelpful antipatterns, I sent out a tweet for help: "What's the most frustrating inconsistent/misleading bit of API you've seen? Looking for cautionary tales!" [...] In the raft of responses (and thankyou all, this was fabulous, helpful and entertaining in equal parts!), there were some definite patterns that I'd like to share with you, in no particular order.

Comments came in from all over and talked about things like:

• Response codes not matching the content (ex. 200 on an error)
• NullPointerExceptions
• Different endpoints for single vs collections
• Order-sensitive XML in requests
• Poor error handling
• Bad documentation
• Incorrect content type handling

So there you have it, the sins to avoid in your own APIs. If you've encountered any of these, please accept my condolences.

The 1.3 release series of the PHP MongoDB driver features a rewritten connection handling library. This is quite a large change and changes how the PHP driver deals with persistent connections and connection pooling.

He starts with an example of a v1.2 driver connection, how the connection is requested from a pool and how, based on the integration of a worker into the connection process, v1.3 handles the connection requests. He includes a bit about replica set connections and authentication connections, complete with PHP code examples showing them in practice.

I've seen a lot of newbies (and not newbies) having problems handling dates in PHP (and even with SQL and another languages). When I see someone having problems with dates, I always ask the same question. I type in a text editor "27/11/2012″ and I ask him: What is it? If your answer is "This is a date" you should continue reading the post.

He talks about how the DateTime functionality replaces (much more effectively) some of the older date handling methods in PHP. He includes a few examples comparing it to date and showing how it can be used to compare dates. He includes a "Dummy" class he mocked up to show how you could work with DateTime to get/set formatted dates, set the format to use and get the current format. As always, he also provides tests for the code as well.

This is just the tip of the iceberg as to what DateTime can do, so I'd suggest checking out the manual page for it to see the full list of features.

It's also feasible to manipulate views in fairly flexible fashion by appealing to the niceties of a few other patterns as well, including the rather underrated Decorators. If you're wondering in what parallel universe Decorators get along with views, in this part I'll be showing how to put them to work side by side in nice orchestration to bring to life yet another view module.

They create a simple example where an HTML element (based on an interface) is rendered - a span tag - with content passed in on creation. They take this same logic and transfer it over to the View handler, making handlers for difference pieces of the content (outer and inner). These decorators are then passed in the data from the view and rendered in order.