What is the difference between throw; and throw ex; in C#? Why does throw ex lose information, how do you rethrow an exception captured on another thread with ExceptionDispatchInfo, and how do throw expressions and ThrowIf helpers fit in?

1. How stack traces are captured

When an exception is thrown, the runtime doesn't immediately build a string. During the second pass of exception handling (unwinding), it records each frame (method handle + IL offset/native IP) into the exception's internal _stackTrace array. Exception.StackTrace formats it lazily into text (using PDBs for file and line numbers if available).

• IL throw (from throw ex; or throw new ...): resets the captured trace, starts fresh at the current frame.
• IL rethrow (from throw;): keeps the existing frames and continues appending as the exception propagates further.

Note: even throw; loses one detail — the line number of the original throw within the same method can be replaced by the rethrow line if the throw and the catch are in the same method (the frame is recorded once). Extracting the throwing code into a separate method or using exception filters avoids that edge case.

2. ExceptionDispatchInfo internals

Capture(ex) copies the exception's current stack trace data and Watson buckets into the ExceptionDispatchInfo object. Throw() restores that captured state into the exception and throws it; the runtime then appends new frames after an "End of stack trace from previous location" marker. The same exception object is thrown (so catch blocks still see the original type and data).

Where it's used in the BCL:

• await on a faulted Task (TaskAwaiter.GetResult → ThrowForNonSuccess → ExceptionDispatchInfo.Throw).
• Task.Wait/Result wrap in AggregateException instead (no dispatch info), which is one reason they're worse.
• Lazy<T> caches and rethrows exceptions from the factory.
• Reflection's MethodInfo.Invoke wraps in TargetInvocationException; code that unwraps it should use ExceptionDispatchInfo.Capture(tie.InnerException!).Throw() to keep the inner trace.

3. Throw expressions in IL

x ?? throw new E() compiles to a branch: if x is null, construct and throw. Because throw is an expression of no type (it never produces a value), it can be used where any type is expected. It cannot be used as a standalone expression statement other than the normal throw statement, and not in arbitrary positions like method arguments (except within a conditional/coalescing expression).

4. Throw helpers and inlining

A method containing a throw is typically not inlined by the JIT (throw sites increase code size and are treated as cold). Patterns like:

public static void ThrowIfNull([NotNull] object? arg, [CallerArgumentExpression(nameof(arg))] string? paramName = null)
{
    if (arg is null) Throw(paramName);
}

[DoesNotReturn]
private static void Throw(string? paramName) => throw new ArgumentNullException(paramName);

keep the check small and inlinable, and move the throw into a separate method marked [DoesNotReturn] (so nullable analysis knows code after it is unreachable). This is why the BCL's ThrowIf... helpers are both readable and fast, and why custom guard libraries should follow the same shape.

5. [CallerArgumentExpression] (C# 10)

The compiler passes the source text of the argument expression as a string:

ArgumentOutOfRangeException.ThrowIfNegative(order.Lines.Count - 1);
// paramName = "order.Lines.Count - 1"

It's also used by Debug.Assert-style APIs and test assertion libraries to show the failing expression.

6. Stack trace quality in async and production

• .NET Core 2.1+ demangles async state machine frames, so traces show OrderService.LoadAsync(Int32 id) rather than <LoadAsync>d__5.MoveNext().
• Deploy PDBs (portable PDBs are small; embed them with <DebugType>embedded</DebugType>) so production traces include file and line numbers.
• Release builds inline methods, so some frames may be missing; that's normal and doesn't hide the origin as throw ex does.
• [StackTraceHidden] (.NET 6) hides helper frames from traces.

Try it yourself

1. Write three nested methods that throw, catch in the outer one with throw ex; and with throw;, and compare ex.ToString().
2. Capture an exception on a thread-pool thread with ExceptionDispatchInfo and rethrow it on the main thread.
3. Inspect ArgumentNullException.ThrowIfNull(customer.Address) and print the ParamName.
4. Look at the JIT disassembly of a method with an inline throw vs one using a throw helper (BenchmarkDotNet DisassemblyDiagnoser).

using System.Runtime.ExceptionServices;

public async Task PayAsync(PaymentRequest request, CancellationToken ct)
{
    ArgumentNullException.ThrowIfNull(request);                     // param name filled in
    ArgumentOutOfRangeException.ThrowIfNegativeOrZero(request.Amount);

    try
    {
        await gateway.SendAsync(request, ct);
    }
    catch (HttpRequestException ex)
    {
        logger.LogError(ex, "Gateway call failed for {PaymentId}", request.Id);
        throw;                         // keeps the Gateway.SendAsync frames
        // throw ex;                   // CA2200: would reset the trace to this line
    }
    catch (TimeoutException ex)
    {
        throw new PaymentFailedException(request.Id, "Gateway timed out", ex);  // context + inner
    }
}

// Rethrow later or on another thread
public sealed class BackgroundJob
{
    private ExceptionDispatchInfo? _failure;

    public void Run()
    {
        try { DoWork(); }
        catch (Exception ex) { _failure = ExceptionDispatchInfo.Capture(ex); }
    }

    public void ThrowIfFailed() => _failure?.Throw();    // original trace preserved
}

// Throw expression
public sealed class Customer(string name)
{
    public string Name { get; } = name ?? throw new ArgumentNullException(nameof(name));
}