Why does C# have a separate rethrow statement (throw;) instead of overloading throw ex?

Question

When throwing an exception preserving the stack trace is the most common desired behavior, and in Java this can be obtained with throw ex;, but in C# throw; must be used. (Please also notice that many of C# programmers will often wrongly use throw ex; instead of throw;).

If sometime the stack trace must be cleared (which is a less frequent situation), it is possible to just throw a new exception like throw new MyException(ex.Message, otherDetails);.

So, considering the above, which is the advantage of having a separate throw; statement in C#?

Or, in other words: why is C# using a special separate statement (throw;), which is less known, for the most used case (when the user wants to preserve the stacktrace), and it uses the more natural throw ex; for the less frequent case (when the stacktrace is cleared)? Is there any other possible use case for which I didn't cover?

Code sample in C# and Java:

// This is the C# design
try
{
//...
}
catch (MyException ex)
{
   // rethrow so that stack trace is preserved
   ex.AppendData(contextVariable);
   throw;
}
catch (PrivateException ex)
{
   // throw new exception so stack trace is not preserved
   throw new PublicException(ex.Message);
}


// This is the Java design
try
{
//...
}
catch (MyException ex)
{
   // rethrow so that stack trace is preserved
   ex.AppendData(contextVariable);
   throw ex;
   // and I can even choose to use something like, where ProcessException(ex) will return the same ex
   throw ProcessException(ex, contextVariable);
}
catch (PrivateException ex)
{
   // throw new so stack trace is not preserved
   throw new PublicException(ex.getMessage());
}

Answer 1

The reason that both throw variants in

catch (SomeExceptionType ex)
{
    frobnicate(ex);
    throw;
    throw ex;
}

exist is because there are use cases for each. Only the first is useful for debugging the code where the exception occurred, but in a mature library, it is almost certain the cause was external to the library (either failure in the hardware/operating system environment, or bad parameter passed by the consumer of the library). In such cases, details of the library innards are not helpful to the programmer using the library, and may in fact cause more confusion.

Furthermore, a closed-source library, especially one accessed remotely in a SaaS model¹ (webservice) may not want to expose implementation details, since these can contain proprietary intellectual property. In such cases, throw ex; is preferable.

You say that Java throw ex; preserves the existing stack trace. How can information leakage be avoided with such a language? One must make a deep copy of everything but the stack trace to a new exception object, which is particularly difficult when exceptions of more derived types are thrown. The C# choice makes both behaviors very easy to obtain.

(You might still want to perform a filtered deep copy, in case information is leaked in other exception properties, such as InnerException. But C# lets you skip the copy step if you so choose.)

¹ Implementation details of a local library can be discovered in other ways. Protection of those details requires a webservice-like execution model, where complete control over the code is maintained.

Answer 2

The semantics of the throw expression; statement are different in C# and Java. In Java, the exception stack trace is captured at the time the exception object is instantiated. In C#, the exception stack trace is captured at the time the exception object is thrown.

In addition, the CLI (ECMA-335) provides a special bytecode instruction rethrow which differs from throw in two primary ways:

1. The exception which is thrown by rethrow is the same exception instance that is currently being handled.
2. The rethrow instruction preserves the original stack trace.

These semantic differences require C# to either provide two different forms for throwing exceptions, or remove the ability of C# users to be able to preserve the original exception stack trace during an intended rethrow operation (not to be confused with the rethrow bytecode instruction, which is specifically made accessible by the throw; syntax).