If you are throwing the exception right after you catch it -- that is essentially the same as not having a try / catch block at all.

Catch specific exceptions that might occur.

For instance, you try to save a file but for some reason it cannot be written:

try
{
SaveFile();
}
catch(FileIsReadOnlyException)
{
//do whatever to recover
}
catch(Exception ex)
{
//If we hit the generic exception, we're saying that we basically have
//no idea what went wrong, other than the save failed.
//
//Depending on the situation you might want to sink and log it, i.e. do nothing
//but log it so you can debug and figure out what specific exception handler to
//add to your code -- or you might want to try to save to a temporary file and
//exit the program.
//
//If you were UpdatingAnAdvertisement() or doing something else non-critical
//to the functioning of the program, you might just let it continue and
//do nothing.
//
//In that case, you can just omit the generic catch.
}

In my opinion, you should generally try and catch exceptions that you would expect to come out of the code you call in the try block, and let the rest get caught elsewhere. For instance:

try
{
// ... some code that you know may throw ArgumentException or any other known exceptions
}
catch (ArgumentException ex)
{
// ... handle the exception with a good idea of why it was thrown
}

In the catch block, you now can handle the error in a clean, specific way knowing that an invalid argument was passed somewhere in the try block. For example, you could alert the user that they have supplied an invalid argument.

If something happened that you didn't expect (e.g. a NullReferenceException) you probably don't know how to recover from it, so by not catching it you delegate responsibility to the consumer of your component to handle exceptional situations in general.

In short, you should catch exceptions when you know how to handle or correct the error, and allow unknown errors to be caught higher-up the call chain

You touched on a very important point here regarding logging the parameters in the method. Too many times I see code where the exception was logged but nothing about the state of the object or method was captured so there's no way to debug it.
–
Doug DawsonAug 19 '14 at 21:01

It's not so much that it's incorrect, as that re-throwing the exception is not what you should be doing. There's a host of reasons that re-throwing it is bad mojo and they touch things like maintainability, performance and good coding practices. Unfortunately, the compiler allows it.

As for when you should be catching the exception,a good rule of thumb is that the exception needs to be caught at the point that you want your code to HANDLE the exception.