Erh, exception types should include an inner exception parameter, for the generic one they wrap. So neither of your two examples are all that great.

Why would I wrap an exception if I don’t plan to have special handling? If it is exception that I didn’t throw because of a business reason, why not just throw the original exception?

If you don't have any special handling, then why are you catching it at all?

That was the "//Do stuff" part, you may want to do some cleanup (in C# usually handled by a finally block or a "using" block), send a custom notification, logging (usually I would just let the client handle logging), etc.

In what case would you ever want the second example?

Always. If you can't resolve the exception and continue processing normally, you should never discard the exception you caught and create a new one of your own. If you must create one of your own, include the one you caught for the additional context.

It's pretty frustrating when you're debugging someone else's code and their error handling just throws away all of the useful information and replaces it with a generic "Something broke" kind of message.

usually you may catch a general exception and throw another one that's caught up the call stack. In this case i think it may be useful for logging additional causes that are not going to be obvious with just the stacktrace(?)