views:

340

answers:

8

I do not have many kinds of Exceptions in my project.
Right now,(we use MVC) I have the try catch encompassing my entire code:

try{
   fronController::dispatch($somthing...);
}catch(Exception $E){
  //handle errors
}

I wonder if there is a good reason to use the try-catch block in as specific as possible way as I can or just keep it general as it is now?

A: 

Be specific, and handle specific errors appropriately.

Dolph
but why? performance? code maintainability...why?
Itay Moav
+1  A: 

If you are using a try block for all your code, you might as well define a default exception handler (see the docs).

Other than that, the size of the try block is up to you, it depends on how fine you want your error handling to be. If you can't recover from any of the exceptions, there's really no reason to be specific, unless you want to log error messages that are specific (but the message of the exception and the stack trace will probably be enough).

Artefacto
A: 

If your handling all of your errors with one general catch you will get minimal feedback and options when an error does occour, it may be fine during development but when its on the front line it could cause you no end of problems.

Be specific and cover all of your bases where feedback is needed and recoverablity is possible.

Yoda
A: 

Different errors may require different responses.

You wouldn't jump out of an airplane in response to every possible problem that could arise. Would you?

Well, that's what your app is doing.

There are situations where an exception can be caught and the application could continue to run. More likely, the app may need to respond to the same class of exception differently in different situations. Perhaps in one function an I/O exception isn't detrimental but in another it is.

webbiedave
+2  A: 

You should be as specific as possible with catching errors in your code. Catching specific errors appropriately increases code maintainability, makes your code structured and organized.

It is also good practice as a convention, especially if you later work on team-based projects and you're not the only one looking at the code.

Personally throwing everything into one try catch block seems to be a code smell.

Anthony Forloney
+14  A: 
erisco
+1 for todays lesson.
zaf
A: 

Remember that exceptions are for exceptional cases. As I understand that, that happens when the error is out of your control. For example, invalid parameters are passed to a public API function, division by zero, situations like 'network connection lost', 'file not found'... this kind of things.

As a general rule, you should catch the exceptions that you know how to handle, like recovering from the error, log the error and propagate it, etc. If you don't know how to handle it, it's better to let it fail. Otherwise your application could be in an error state that you may not want.

So answering your question, it's better to be as specific as possible since every exception should be handled only if you know what to do with it (silently swallowing is a bad idea). If not just let the exception notify the user that something went wrong. Or if you want to, catch the exception to log the error and rethrow it.

There's good discussion here for C++, but the general concepts apply. I found the java tutorials on exceptions also very good.

Pin
+1  A: 

generally throw locally, catch globally unless an exception handler is specific to a function in which case handle locally.

 class fooException extends Exception{}

 // DB CLASS

 public function Open(){
    // open DB connection
    ...
    if ($this->Conn->connect_errno) 
      throw new fooException("Could not connect: " . $this->Conn->connect_error);
  }

 // MAIN CLASS

 public final function Main(){
    try{
      // do stuff
    }
    catch(fooException $ex){
       //handle fooExceptions
    }
 }
f00