Page 3 of 3

Re: Why (and when) to use Exceptions

Posted: Wed Sep 10, 2008 12:48 pm
by Christopher
I agree with your comments. The point is to understand how return values and exceptions work, and use the appropriate one to solve the problem you are working on.
webaddict wrote:There is another difference. Exceptions not only bubble up multiple layers, they also do it immediately after being thrown.
This is a good descirption of a key difference. Bubbling up immediately through multiple layers is a key reason to use exceptions. That can really clean up code. However, if you don't have multiple layers or you want to do some things before reporting the error then return values may be useful. As I said, it depends on the design and needs of the code.
webaddict wrote:Conclusion: seriously, there is no use on discussing the filosify on the name exception. It is a tool to achieve a goal, I'd recommend using it as such..
Yes! :)

Re: Why (and when) to use Exceptions

Posted: Mon Sep 22, 2008 8:35 pm
by 8ennett
My logic is that errors caused by the end-user (i.e. they entered a negative duration in a text-box) should be handled gracefully, but errors caused by developers or calling-code should result in nasty hard-errors--that way the calling code can be fixed sooner rather than later.
This is pretty much all I was trying to input to the discussion really, but alas my own terminology failed me and i wasn't able to properly illustrate what I was trying to say. Nice healthy debate going on though, interesting to see the different pov.

Re: Why (and when) to use Exceptions

Posted: Wed Sep 24, 2008 8:47 am
by Jenk
I'm part way through reading the book "Clean Code" (ISBN-13: 978-0-13-235088-4) which has a section on "Prefer Exceptions to Returning Error Codes" and the first sentence nicely summarises my opinion:
Returning Error Codes from command functions is a subtle violation of command query separation.
:)

Re: Why (and when) to use Exceptions

Posted: Wed Sep 24, 2008 11:29 am
by Christopher
We addressed the issue of command query separation above by showing that in OO you would implement one method that performs the action and possibly returns data, and a separate method that check if an error condition exists. This is the same what an exception does by separating the two by using a language construct.

PS - I am not sure of the real-world need for command query separation. There are millions upon millions of lines of code that break that separation with no ill effects. We're not programming in Eiffel here. ;)

Re: Why (and when) to use Exceptions

Posted: Wed Sep 24, 2008 3:39 pm
by josh
webaddict is spot on about the bubbling up of exceptions, exceptions are also great because you can extend the exception object and make special case exceptions that each have their own abstracted behaviors, so common error handling functionality is pushed back into one common area thats easy to maintain / update.

Over-use of exceptions on the other hand can actually become a bottleneck for your application, so like arboint said its important to not use them for things that should be return values.. A search that produces no results should be handled by passing NULL or 0 or an empty array or something, because no data in the database is a perfectly common scenario, in my opinion exceptions are more for communicating error codes across application layers, for example if your'e codeing using a web service, exception handling should be written in. Basically I think they should be used when you can't restructure the code to handle a condition gracefully without using exceptions, a model using another model is a good example... but it would be more "correct" to catch and handle the exception within the model being called like..

Code: Select all

 
class modelA
{
 function __construct() { throw new Exception('An exception occured');
}
 
class modelB
{
 function __construct{
  try
  {
   new modelA();
  }
  catch( exception $e )
  {
   //whatever
  }
 }
}
 
or would it be better for modelA to catch its own exceptions and just return false? That is the part thats still fuzzy to me... in this example im checking that the model instantiated correctly which is a bad example, but lets say I was just calling a method instead of instantiating the class, and I knew the method was callable I just didn't know if that method was going to produce an exception

Re: Why (and when) to use Exceptions

Posted: Wed Oct 01, 2008 12:58 am
by Selkirk
You may find my presentation interesting:
Exceptional PHP: When good code goes bad (PDF)

Re: Why (and when) to use Exceptions

Posted: Wed Oct 01, 2008 11:03 am
by Christopher
Hey Jeff, very informative presentation. Thanks for the link. I see you have moved out here to California. Congrats on the (no longer) new job!

Re: Why (and when) to use Exceptions

Posted: Mon Sep 13, 2010 6:34 am
by kpzani
Just thought I'd add my experience to this one. I've used exceptions a lot in .NET programming but havent really bothered in PHP up till now.

My system was always to use exceptions when writing code that talks to code e.g. custom classes, connection scripts etc
and normal error trapping techniques for code that talks to a user.

My theory is this, normal error trapping works great and it fits the way most of us think. If we have a form doing something then we filter/clean the input then check it and react appropriately if its garbage.
When writing more abstract code like a page templating system, we can use try catch blocks to trap strange problems and also throw our own. And we can easily switch into this method when dealing with custom classes and other api type stuff.

Hope that makes sense, it's a close to a rule as I can articulate.

Kris