If you're a NetBeans user and have been frustrated by it's default handling of non-PHP extension files as PHP, you should check out this new post from Sachin Khosl on digimantra.com on how to fix the issue.

You love coding in Netbeans and you find it pretty uneasy when it does not function the way you want it to. That was the same with me when I started development in drupal and I was unable to associate the .module as PHP in my favorite editor Netbeans. However with little play around with options I was able to associate .module files as PHP file in Netbeans IDE. So for doing so follow [these] steps.

You can change the setting for plenty of different extensions (and add your own custom ones) in the Options under the Miscellaneous section's Files tab. Check out this screenshot to see the location.

Marco Tabini has taken a different tack on error handling in his latest post. He suggests that developers need to spend a little less time trying to prevent so many errors and a little more time handling the ones that do happen.

When an error occurs, the vast majority of the web-based application code that I see during my reviews performs the software equivalent of running around with its head cut off: the developer spends an inordinate amount of time and resources trying to make the software look like what was essentially a catastrophic failure was nothing more than a small temporary hiccup.

[...] In reality, by the time an error has occurred, there are only two possible outcomes: either you expected the error to occur, in which case you have already written code to handle the failure, or you didn't, in which case your main focus should be to use the error as a learning opportunity.

Marco suggests alternatives to this usual worry and hysteria - spend more time ensuring that (if something does fail) there won't be any more damage, let the IT team know as soon as you find the issue and testing before you fix (reproduce the error before you dig in to try to fix it).

DevShed has posted the latest article in their "introduction to views in CodeIgniter" series - a look at working with the views to add more layout/design to them with CSS.

Now it's time to continue exploring the capabilities given by CodeIgniter when it comes to handling views. Since the visual appearance of the web page mentioned above was pretty rudimentary, in this second article I'm going to improve it a bit to make it look more appealing and professional.

To add in their CSS, they update their header_view.php file to includes the styles in the template. The views for each block are then loaded via the controller - header, content and footer areas.

Chris Jones has changed his stance on something he's been recommending PHP users compiling the OCI8 libraries into their installation - the use of enable-sigchild.

I am no longer blindly recommending using --enable-sigchild when configuring PHP with the OCI8 extension. I used to do this as a catch-all. It might have saved some users grief, and did little harm. With changes in recent versions of Oracle and my gut feel about common usage, it will be less confusing not to mention it as a general suggestion.

The point of using the compile flag was to help with the opening/closing of connections to Oracle server processes, but there's a better way he recommends now - using a "BEQUEATH_DETACH" option of "YES" in the sqlnet.ora/Apache config. If that doesn't work, then look into recompiling with the enable-sigchild option.

Jani Hartikainen has written up a new post looking at error handling in one of the more popular PHP frameworks - the Zend Framework.

In Zend Framework based applications, error handling is typically done using the error controller, but there are different ways to send the execution to it - some better than others. Let's look at some ways to trigger the error controller and how to have it handle different error conditions.

He walks through the steps to create the Error controller, change the front controller to use it and add in a few different kinds of actions to handle the various error types that might come up (like "page not found" or "not authorized"). Errors can then be forwarded to each of the actions by the resource the visitor errored from. Of course, he also mentions that exceptions can do something even better - handle the error without all of that messy forwarding around. (There's an example of that version too).

Johannes Schluter recently looked at one of the new features coming with PHP 5.3 - the goto functionality:

Over the last few days I already mentioned a few hidden gems from PHP 5.3. Now at Christmas I wanted to take a look at some new language feature of the upcoming PHP version: Added "jump label" operator (limited "goto"). (Dmitry, Sara)

No, its not the sort of "goto" you're thinking of - its a bit more limited than that. Johannes mentions that it only allows you to jump within the same execution unit and you can't jump into loops. Used incorrectly, it can be bad but he points out two useful instances - one being a code generator and the other an instance where you might need to drop out of code but not kill off the script in the process (sample code is included for this second one).

On DevShed today, there's a new tutorial posted looking at two things that can cause headaches for PHP developers (especially when evaluating and comparing values) - nulls and empty strings.

Anyone who has programmed for any length of time has encountered the concepts of null and empty strings. They are not the same, and confusing the two can cause some serious problems. This article deals with these concepts in the context of PHP and MySQL.

They start with a bit of a quiz before getting into how to handle them correctly - making null "safe" and working with it correctly in a MySQL context. SQL statements and table structures are included for their examples.

Chris Hartjes has posted his method for creating a development setup that lets you use multiple environments with your code.

In anticipation of my talk at PHP Quebec 2009 I've been going over my slides and thinking about what I'm going to update for it. One little nugget I'd thought I'd share is one way of handling having multiple environments your code must run in.

It uses a PHP variable in the $_SERVER superglobal - a custom one, APP_ENV - set by the application and checked to ensure global options are correctly set.

DevShed continues their series looking at exceptions in PHP with this second part focusing on throwing and handling customized exceptions in your PHP5 application.

While the built-in exception system that comes bundled natively with PHP 5 is usually good enough to handle errors and other critical conditions during the execution of a given web application, it's worthwhile to mention that there are a number of additional cases where it is necessary to implement an exceptions system that can handle different failures in a more specific way.

They show how to trigger some basic custom exceptions and detail the creation of a class to handle catching these exceptions in a bit more OOP kind of way.

In a new post to his blog, Michael Kimsal points out a post from his brother (Mark) that wonders if your framework handles 404 errors the best/most useful way it can.

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.