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.

(1)
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.

(2)
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.

(3)
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.

It obviously gets annoying when you have to write a try/catch block for nearly every time you access an object, so I've come up with some guidelines for throwing exceptions:

(1) Don't throw an exception if you can return a null value that is unambiguous. For example, if a function is supposed to return the contents of a file as a string, then the return value should never be null if the operation was successful (even if the file is empty, an empty string can be returned). In this case, it is OK to return a NULL value if there is a problem, because a VALID return value will never be null. This guideline should only be used if #6 is not violated.

(2) Don't throw an exception if it is more appropriate to just return a 'false' value. For example, if a function is supposed to save an object's modified values, return a true/false value rather than throwing an exception. The only problem (usually) that can go wrong in such a function would be a file-related problem (such as the file being read-only or non-existant), which is easily found regardless of a descriptive error message.

(3) Always throw an exception if there is a problem in the constructor.

(4) Throw exceptions if invalid input is given (for example, if a string is given as an argument to a function when an integer should have been given). This is especially important when validating database input. Input that is given to the function should have already been checked for validity.

(5) Throw exceptions when the program absolutely cannot continue to run. If the program CAN continue to run after a major problem, it is probably best to allow it to do so, and just log the problem or e-mail the administrator.

(6) Throw an exception when the problem that caused it is ambiguous and/or hard to pinpoint. The exceptions should be descriptive of each problem. For example, when validating input, don't just throw an exception that says 'Invalid input'. Throw an exception that says 'Invalid input given to xxxx_function in SomeObject: $username must be <= 15 characters'.