This is more a question of best practice than anything. Ive a fairly good grasp on how to use and extend exceptions in php, my question is where do we use them?
Say I have a method add($name, $pass) in a class user(). This method checks to see if the givin username exists, and if not, adds a new user. Now obviously, there is a few reasons such a method might fail. Firstly, the db connection (setup in the class's __construct()) might fail. Secondly the username may already exist, and thirdly, well maybe the query just fails.
I think its appropriate to throw an exception upon failing to connect to the database, and also on the query failing, but Ive mixed feelings about using exceptions in the case of the username already existing.
I can see that by using exceptions here it would be easy to format a message to the user especially if I build my own exception class's for each possible error. It just seems to me that having a username already exist isn't really what I would consider an error as such.
I think I would like to use exceptions in these cases, Im just not sure if its the done thing. Is it right to use exceptions as such control structures? Is there a best practice for this sort of thing?
ps: I work with php5 exclusivly so thats not a concern. Also (obviously) I would be returning false if not an exception.
Thoughts?I like to think of an exception as an emergency in the execution of the program. The context of the code being executed would define the kind of emergencies which may occur. I use exceptions where continuing the current flow of code would be pointless or unncessary.
On one of my sites has a user based authentication mechanism which upon failing to authenticate a user, either using a session ID or a user name and password, an eception is thrown. The system also verifies the credentials using a database, if the database query fails, it will throw a different type of exception.
I have also built a system which retirieves and sanitizes form variables from the $_POST and $_GET arrays. If an attempt is made to get a form variable which does not exist, I throw an exception. The beauty of this is that the exception travels up the execution stack, nuking each level until it gets caught - this means you do not have to manually exit all your functions with return values indicating failure.
In your case, I would say yes, it is ok to use exceptions for conditions such as "username already exists" or "invalid characters", etc. All these prevent the add function from adding the user and would consitute and emergency.
Where wouldn't I use exceptions? I would not use exceptions for informational purposes (i.e: to tell me the user has been created or to tell me the acceess level of the user). Or in order to execute alternate paths of execution (i.e: throw an AdminException if the user is an admin, catch it and do something completely different). Used like this they begin to cause code to mimic the spaghetti code seen in the days of BASIC.One rule of thumb I apply (there are probably others, but I haven't formulated them yet), is that if something can fail due to influences from the outside world, then I handle the failure by throwing an exception. Failure to open a file that I should have been able to because some twonk deleted it, or to connect to a database because the power supply burned out on the db server, are exceptional circumstances.
It's like my daily routine: it doesn't include branch points to cover Acts of God (I'll deal with an earthquake when it happens - but I don't bother checking to see if one is happening).BUMP!
Excellent comments
and I think a more visual example of what visualAd and Weedpacket were talking about can be found in this article (<!-- m --><a class="postlink" href="http://java.sun.com/docs/books/tutorial/essential/exceptions/advantages.html">http://java.sun.com/docs/books/tutorial ... tages.html</a><!-- m -->). But I think handling errors, no matter what you do is going to be a pain and take up too much space in the source code.
Say I have a method add($name, $pass) in a class user(). This method checks to see if the givin username exists, and if not, adds a new user. Now obviously, there is a few reasons such a method might fail. Firstly, the db connection (setup in the class's __construct()) might fail. Secondly the username may already exist, and thirdly, well maybe the query just fails.
I think its appropriate to throw an exception upon failing to connect to the database, and also on the query failing, but Ive mixed feelings about using exceptions in the case of the username already existing.
I can see that by using exceptions here it would be easy to format a message to the user especially if I build my own exception class's for each possible error. It just seems to me that having a username already exist isn't really what I would consider an error as such.
I think I would like to use exceptions in these cases, Im just not sure if its the done thing. Is it right to use exceptions as such control structures? Is there a best practice for this sort of thing?
ps: I work with php5 exclusivly so thats not a concern. Also (obviously) I would be returning false if not an exception.
Thoughts?I like to think of an exception as an emergency in the execution of the program. The context of the code being executed would define the kind of emergencies which may occur. I use exceptions where continuing the current flow of code would be pointless or unncessary.
On one of my sites has a user based authentication mechanism which upon failing to authenticate a user, either using a session ID or a user name and password, an eception is thrown. The system also verifies the credentials using a database, if the database query fails, it will throw a different type of exception.
I have also built a system which retirieves and sanitizes form variables from the $_POST and $_GET arrays. If an attempt is made to get a form variable which does not exist, I throw an exception. The beauty of this is that the exception travels up the execution stack, nuking each level until it gets caught - this means you do not have to manually exit all your functions with return values indicating failure.
In your case, I would say yes, it is ok to use exceptions for conditions such as "username already exists" or "invalid characters", etc. All these prevent the add function from adding the user and would consitute and emergency.
Where wouldn't I use exceptions? I would not use exceptions for informational purposes (i.e: to tell me the user has been created or to tell me the acceess level of the user). Or in order to execute alternate paths of execution (i.e: throw an AdminException if the user is an admin, catch it and do something completely different). Used like this they begin to cause code to mimic the spaghetti code seen in the days of BASIC.One rule of thumb I apply (there are probably others, but I haven't formulated them yet), is that if something can fail due to influences from the outside world, then I handle the failure by throwing an exception. Failure to open a file that I should have been able to because some twonk deleted it, or to connect to a database because the power supply burned out on the db server, are exceptional circumstances.
It's like my daily routine: it doesn't include branch points to cover Acts of God (I'll deal with an earthquake when it happens - but I don't bother checking to see if one is happening).BUMP!
Excellent comments
and I think a more visual example of what visualAd and Weedpacket were talking about can be found in this article (<!-- m --><a class="postlink" href="http://java.sun.com/docs/books/tutorial/essential/exceptions/advantages.html">http://java.sun.com/docs/books/tutorial ... tages.html</a><!-- m -->). But I think handling errors, no matter what you do is going to be a pain and take up too much space in the source code.