Wrox Programmer Forums

Need to download code?

View our list of code downloads.

Go Back   Wrox Programmer Forums > PHP/MySQL > Pro PHP
Password Reminder
Register
Register | FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read
Pro PHP Advanced PHP coding discussions. Beginning-level questions will be redirected to the Beginning PHP forum.
Welcome to the p2p.wrox.com Forums.

You are currently viewing the Pro PHP section of the Wrox Programmer to Programmer discussions. This is a community of tens of thousands of software programmers and website developers including Wrox book authors and readers. As a guest, you can read any forum posting. By joining today you can post your own programming questions, respond to other developers’ questions, and eliminate the ads that are displayed to guests. Registration is fast, simple and absolutely free .
DRM-free e-books 300x50
Reply
 
Thread Tools Search this Thread Display Modes
  #1 (permalink)  
Old January 4th, 2005, 12:43 AM
Registered User
 
Join Date: Dec 2004
Location: , TX, .
Posts: 9
Thanks: 0
Thanked 0 Times in 0 Posts
Default 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.

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

Reply With Quote
  #2 (permalink)  
Old January 15th, 2005, 02:37 PM
Registered User
 
Join Date: Dec 2004
Location: , TX, .
Posts: 9
Thanks: 0
Thanked 0 Times in 0 Posts
Default

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'.

Reply With Quote
Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
exceptions Maxxim BOOK: ASP.NET 2.0 Website Programming Problem Design Solution ISBN: 978-0-7645-8464-0 3 October 18th, 2008 12:34 PM
Nested Exceptions in c# JelfMaria VS.NET 2002/2003 5 June 28th, 2005 01:15 AM
Web Exceptions dotnetprogrammer VS.NET 2002/2003 0 November 3rd, 2004 03:39 AM
throwing exceptions...!? jacob ASP.NET 1.0 and 1.1 Basics 3 October 9th, 2003 03:37 PM
Exceptions and errors nbnelson C# 0 August 5th, 2003 11:24 AM



All times are GMT -4. The time now is 01:56 PM.


Powered by vBulletin®
Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.
© 2013 John Wiley & Sons, Inc.