Why (and when) to use Exceptions

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Re: Why (and when) to use Exceptions

Post 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! :)
(#10850)
User avatar
8ennett
Forum Commoner
Posts: 63
Joined: Sat Sep 06, 2008 7:05 am

Re: Why (and when) to use Exceptions

Post 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.
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Re: Why (and when) to use Exceptions

Post 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.
:)
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Re: Why (and when) to use Exceptions

Post 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. ;)
(#10850)
josh
DevNet Master
Posts: 4872
Joined: Wed Feb 11, 2004 3:23 pm
Location: Palm beach, Florida

Re: Why (and when) to use Exceptions

Post 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
Selkirk
Forum Commoner
Posts: 41
Joined: Sat Aug 23, 2003 10:55 am
Location: Michigan

Re: Why (and when) to use Exceptions

Post by Selkirk »

You may find my presentation interesting:
Exceptional PHP: When good code goes bad (PDF)
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Re: Why (and when) to use Exceptions

Post 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!
(#10850)
kpzani
Forum Newbie
Posts: 1
Joined: Mon Sep 13, 2010 6:27 am

Re: Why (and when) to use Exceptions

Post 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
Post Reply