Fair enough. Try running the code segment below. The two strings, ex1 and
ex2 are always going to be different. Specifically, the line they each say
originally caused the exception changed.

Once you've run it and proven this, change the "throw ex" to just "throw"
and see what happens.

void Go()
{
   string ex1 = string.Empty;
   string ex2 = string.Empty;
   try
   {
       try
       {
           int zero = 0;
           int x = 1 / zero;
       }
       catch (Exception ex)
       {
           ex1 = ex.ToString();
           throw ex;
       }
   }
   catch (Exception ex)
   {
       ex2 = ex.ToString();
    }

   if (ex1 == ex2)
       System.Diagnostics.Debug.WriteLine("They're the same");
   else
       System.Diagnostics.Debug.WriteLine("They're different!");
}

When the code shown below executes the "throw" statement it causes code in
the runtime to execute (think of it as microcode).
This code performs a number of functions.
   If the argument to the throw statement is a valid exception object it
sets the stack trace in that object to start at the current line of code. If
there is no  exception object specified (a naked throw) it rethrows the
current exception object in the surrounding catch block without resetting
the beginning of the stack trace. However, a bug in the 1.1 framework resets
the stack trace anyway - this is supposed to be fixed in the 2.0 framework.
This implies that a naked throw statement is only legal when used within a
surrounding catch block.

 Thus, the main difference between the statements
throw (ex);
   and
throw;

is that the first form sets the stack trace to the current LOC and the
second does not change the beginning of the stack trace (at least, it's not
supposed to, starting with the 2,0 runtime).

The practical difference to us, the application writers, is that using the
naked throw preserves the original stack trace while the second form,
throw(ex) throws away the original start of the stack trace and replaces it
with a stack trace that begins at the line where the exception is rethrown.
As this loses information, and is potentially misleading, it has little to
recommend it. The only possible use where that loss is good is if it is used
in conjunction with some other security restrictions to hide sensitive data.

Another form that I find more useful is the catch-wrap-rethrow, as shown
here...

catch(Exception ex)
{
 throw new ApplicationException("Useful context information here.",ex);
}

This creates a new exception, with a stack trace beginning at the line of
code of the throw statement, and the original exception is preserved along
with its stack trace as the InnerException object. This loses no information
and adds valuable new context information to help the user troubleshoot the
problem.

Dave