When to use Exceptions
I think this question deserves debate. When should exceptions be used, and when is it OK to just return a 'null' or 'false' value?
Obviously, throwing an exception will make the problem easier to find when it comes up, but is it necessary in certain situations?
I'll start with 2 obvious examples and move on to a more questionable one.
Suppose you have an object called "User", which accesses a database table. When one of the object's "setXXX" accessor methods is called, it updates the table (or, when a "save" method is called, if you will). So, if someone calls "$userObject->setUsername(null)", where the Username field of the table must NOT be null, should an exception be thrown? It seems quite fatal to me, and therefore one should be thrown.
You are writing a function to check if a user matching a given username exists in the database, called 'userExists'. It takes one parameter, the username to be checked. Suppose the calling function passes a NULL value as the username. The return value should be 'false' in this case because a NULL input to such a function should never be fatal.
Now, suppose we only want to allow one logged-in user to be accessible to the program at a time, so we have a PRIVATE constructor on the User, and we implement a singleton-similar design pattern to access the logged-in user via a 'getUserObject' method. Therefore, whatever user is currently logged in on the system is held in the static 'userObject' object. In this case, if the user is NOT logged in and the 'getUserObject' method is called, should an exception be thrown?
The answer is not so obvious. A problem like this could take hours to find if no exception is thrown, but it is also less likely to actually cause a problem (in most cases). Is it worth the extra clutter to throw an exception?
I would opt for throwing an exception, since it provides the calling function with a way to avoid the problem if it is not important (by either making sure the function isn't called when a user is not logged in, or by using a try/catch block), and it throws up a big red flag to the calling function when it IS a problem.
Exceptions are obviously a nice tool to use, but they cause a lot of clutter as well. I wrote a User class a few weeks ago that checked the constraints of EVERY input it received before it saved the changes to the database. It made sure all of the data was within bounds, not null, etc. Needless to say, I had about 1000 lines of code, with 900 of them being constraint checking & exception throwing. I could have thought of a better way of authenticating input to reduce clutter and encourage code reuse (through a 'Constraint' class, maybe).
After reviewing the above examples, it seems that any return value that could possibly cause a fatal problem should be replaced with an exception. So, when in doubt, throw an exception!
Take what I say with a grain of salt, though. I am just a newbie ;) That's why I posted this! Please give your input.