As a programmer I know that when the deadline is approaching and the blood's caffeine levels are sliding, syntax errors raise faster then you can say "OMGWTF!" Thus this guide is meant as a quick help for those who are either new or tired.

Problem #1: Not enough cowbell

Oftentimes I'll be typing along, writing new or modifying some existing code and when I go to test it, BAM, unexpected something in the syntax. Generally this is a missing bracket or parentheses, usually because I had a complex IF statement or added a conditional to section off some code. Of course there are other times that (when using PHP) those end of line semi-colons are missed.

PHP syntax errors are there for a reason, which is why I always say to have PHP (at the ini or .htaccess level) set so that errors are always displayed and error reporting is set to E_ALL or even better E_STRICT. Because otherwise, you'll have no idea what you missed or forgot in terms of syntax.

Having the error reporting turned on should also help you develop better coding practices as well as show you what you could be doing better. (I.e. what PHP complains about but lets you do anyway.)

Additional reading:
http://php.net/manual/en/ref.errorfunc.php....display-errors
http://php.net/manual/en/function.error-reporting.php
http://php.net/manual/en/ref.errorfunc.php...rfunc.constants


Problem #2: Danger Will Robinson, danger!

When writing code for oneself, one tends to not care or think there be a need for error reporting. For me, I sit on the fence for this, however WHENEVER I write code for someone else I always try to include some sort of reporting functionality.

Basically, errors should always be raised when data is not what you expect and should always be fatal if you can't continue with what you have. For instance, when you're trying to get the a user's ID number from the cookie to save something to a database, but are only getting "HAHA I HAXED YOU!!!", you should raise some error. Typically I would do something like "Wrong user ID specified." and continue on as if the user was a guest.

I generally raise fatal errors when I'm attempting to send or receive data from a remote source (like a database). Usually when writing a SQL statement, I'll check or otherwise sterilize each piece of data going in so the *SQL won't raise any of it's own errors. However since I can't plan for all situations, it's still good to check the problems. Problems ran into could be anything from people requesting data that's been deleted or even non-existent! Like if I put a topic ID in a URL for Dream.in.Code! Normally I'd never come across a situation where the ID is so high that it hasn't been created yet. However someone who is malicious may try to gain info on the database or even inject his own SQL.

Additional reading:
http://en.wikipedia.org/wiki/SQL_injection
http://www.youtube.com/watch?v=MJNJjh4jORY (Actually a short video)

Coming next, Problem #3: How I mine for fish?

I never realized just how easy it is to use a sql injection like that!!!

i throw exceptions when error condition happens. it is so easy to handle at any levels. i always set error reporting to E_ALL and display errors to false escpecially on live web sites. then get the errors in the error log.

http://www.tizag.com/mysqlTutorial/mysql-p...l-injection.php

A nice article on the topic of SQL injection, about it and how to prevent it.

Yours,
Shane~

This post has been edited by ShaneK: 27 May, 2009 - 05:14 AM

Tizag is in my favorites too!

PS.. love the signature.. counting sheep!

LOL