CodeAngel.org

//NOTE THIS IS NOT POSSIBLE, IT'S BULLCRAP!!
try {
  throw new Exception("throw an exception");
} catch (Exception $e) {
  //do something with a thrown exception.
} else {
  //do something if there wasn't an exception thrown.
}

This tutorial isn't specific to PHP, It applies to all languages that support exceptions. Error checking is very important in any language. You should be checking for any possible place where an error can occur.

 
$db = new my_db('host','user','pass','db');
if($db->connect_error()){
  die("Error Connected to the Database");
}
$stmt = $db->prepare("SELECT * FROM table WHERE field = ?");
if($db->error()){
  die("Could not prepare query");
}
$stmt->bind_param(1,'value');
$stmt->execute();
if($db->error()){
  die("Could not execute query");
}
 

With exceptions this becomes a lot cleaner. The error checking can all be moved to one place.

 
try {
  $db = new my_db('host','user','pass','db');
  $stmt = $db->prepare("SELECT * FROM table WHERE field = ?");
  $stmt->bind_param(1,'value');
  $stmt->execute();
} catch (Exception $e) {
  die($e->getMessage());
}
 

Exceptions are great. But they're meant to track one kind of error only: Exceptional Errors. Exceptional errors are non-recoverable. Exceptional errors are things that are unexpected. Exceptional errors should not have happened in any normal sense. If you remove all Exception handling in your code, the code should still run (that is if nothing exceptional happened.)

Here are some examples where an exception is not warranted:

• User enters an incorrect password, you should expect this
• A user enters alpha characters in a phone number field that should only contain digits, WRONG, but you should expect this behavior
• Checking that a file exists that you have no idea if it should exist or not.
• A Search returns no results.

Examples of where exceptions may be warranted:

• A database connection fails that should be able to connect.
• A SQL query cannot execute because it is malformed.
• Checking that a file exists that should be there.
• A Parser cannot parse because the data is malformed.
• Checking for existence of required properties in a class that should have been set before a method was run.

Why this distinction of when to use exceptions? The biggest reason is that exceptions moves the code execution to a catch statement much like goto moves code execution to a different part of the program, and can create spaghetti code if used incorrectly. A normal day to day catch statement should show a friendly error to the user, log or show the exception, and halt the execution flow.

I hope this article helps readers understand when to use exceptions, and if it can prevent just one person from designing their code like the user in the first paragraph, it did it's job.

References:
Hunt, Andrew and Thomas, David The Pragmatic Programmer Addison-Wesley, Feb 2006.