Everyone wants to think they’re a great programmer. Great programmers create bugs just like greenhorn programmers, the difference is, great programmers can turn around bugs quicker. How do they turn bugs into working code so fast?

• History always repeats itself
• Handle error cases up front

Remember, history always repeats itself. You’ll find yourself making the same rudametary bugs for awhile. If you know your own fatal flaws you’ll be ready to fix your bugs before you even start. How many times have you said “GRR! I always do that!”? Enough to know your own common mistakes and eventually learn from them. But remember, history always repeats itself.

Next, handle your errors up front before you put your code out into the wild. Software development is not an easy task and it comes with a lot of headache and head pounding frustration. That is why we’re a special breed; not everyone can code. The best rule to follow, expect to have bugs and plan accordingly.

When you come to a logical branch in your software think “how can this go bad?” Because, in a few situations, it will go bad. It is said that developers only write three to four lines of working code a day. That might be a bit off by todays standards (or too high?) but it shows us something: We code a lot but only write a few working statements.

Consider this case: When a user comes to your website, you want to show them a special “tip of the day” which is stored in a database on the back-end of your site. First, it is only displayed on the homepage. Second, the tip is extracted from a database.

What can possibly go wrong? Let’s consider the most basic logical block: you’re either a) on the homepage or b) not on the homepage. Seems reasonable, and there may not be any chance for failure considering the situation.

But what about extracting the data from the database? Sounds simple, query the database and present the data to the user. But what if…

• The tip of the day record is empty (’null’)
• The tip of the day record is non-existent, for example, the record is missing.
• The database is offline due to a fatal error.

In many development examples all three issues resolve to the same error “cannot get tip of the day.” How is that useful to the developer? The error is too general and doesn’t give you a place to start in your debugging process. Secondly, what if the site is live and 10% of your users receive this error randomly throughout the day? How do you track it down?

An experienced developer will tell you to be more wordy with your error and less general. They’ll also tell you to make it sound intelligent. Each of your three error cases should be caught independently and presented so it makes sense to the user and to the developer:

• The tip of the day cannot be displayed: Database is down, please try back later.
• The tip of the day cannot be displayed: No tip of the day has been written.
• The tip of the day cannot be displayed: The tip of the day has not been configured.
• Error 106: Tip of the day has not been configured.

On occasion techy terms like “Error 106″ can be utilized for large scale projects that have an error code directory where support techs can lookup “106″ and have it describe the error in ugly detail. However, in many web development scenarios, an error that is plain English (or German, or French or Italian) is best suited for the situation.

First, the error should be written well, so the users know the general state of the situation. In the case of “please try again later” this might be a good error for inter-mitten issues in scaling or problems you’re working on fixing. If you do not tell them to try again later they may never come back (let’s face it, most won’t anyway).

Secondly, keep each error unique for the situation. This will help you map down the error in your logical branches (i.e if statements) so you don’t have five places the error can be generated. Having more than one area for each error means you’ll be spending n number of times reproducing the error (since you’ll probably need to test it n different ways).

If you have an error in a looping block, present the error with some “index” so you know roughly which iteration of the loop you were in. For example: “Cannot obtain tip of the day record (iteration: 6).” The iteration may help you track down the nature of the situation, especially if the iteration is “-1″ or “4294967295″ (probably some type of infinate looping situation).

Third, keep it simple! A five paragraph error is ugly and really is too much information for the user. If you’re finding yourself writing a hugely complex error you may want to utilize the error code system and keep the complexities in a document, appendix, error chart or comments in your code.

Lastly, install a dictionary or spell check on your compiler or test your errors by copying them into Microsoft Word or other word spell check system to make sure they’re spelled correctly. You’ll write many error paths that “will never be hit” so you may go live without properly testing all the negative cases. But, once in the wild, you’re code is at an extreme disadvantage and you may hit some of those errors you didn’t think possible. Might as well spell them correctly so you don’t look like a greenhorn.

Bad error text:

• Error 145
• Cannot find tip
• Unexpected critical failure
• Uninitialized value at line 4, in /web/htdocs/codeparadice/user.php

Error codes are nice, but not when that’s all you present the user. It’s unprofessional and doesn’t give the user an clue what they might have done to generate the error. This is why “Error 404″ in your web browser supplies a reason “web page not found or server not available.” 404 means nothing to your mother browsing the web with Internet Explorer, but the reason text lets her know why shes not getting the page she wants.

Having errors that are too simple, such as “Cannot find tip” leads to vague error text and, more than likely, you’ll find the desire to pepper your error conditions with this text since its so vague and reusable (bad monkey!)

Unexpected critical failure! First, you’ll scare your audience quickly and they’ll never come back. Secondly, “unexpected” isn’t needed, who expects errors? Third issue, it’s too vague and will not get you to the root of the problem.

The last error is probably an untrapped or uncaught exception. This is an error that you didn’t test for but the compiler/interpreter caught for you-but doesn’t know what to do with the issue. It’s telling you where your code is bad and that you should go fix it. This is unprofessional and, although specific to the line of code, doesn’t really give the user a clue what’s wrong.

In the worse of cases, the details provided are so specific that hackers can take advantage of this. They now know your directory structure and can work known exploits to try to read into certain directories to find your private data. Very very bad. This is especially true with many database errors, which is why CMSs like drupal usually have programming interface to present errors to the user.

Uncaught exceptions are those you didn’t know could exist or didn’t test for correctly (or at all). So how do you fix them? By handling all error conditions! This may include initializing variables and testing their state before printing them or utilizing them in mathematical operations and function calls is important. Always initialize your variables to a known state so you can tell if they’ve been set correctly or not.

Once you get in the habit of testing your code by eye before you execute it the better chance you’ll have of catching the unexpected before it occurs. If you’re unsure of the nature of a return code or state, test it and generate a useful unique error before you move on to other coding endeavors.

Expect the unexpected because there is a high chance that you’ll hit them, no matter how great a developer you think you are.