How does exception chaining (via the cause mechanism, initCause() or a constructor accepting a Throwable) preserve the original root-cause exception when wrapping and rethrowing a different exception type, and why does this matter for debugging?

When catching a lower-level exception and throwing a different, higher-level exception more meaningful to the caller (a common pattern for translating a checked exception into an unchecked one, or abstracting away an implementation detail), passing the original exception as the cause (via a constructor like new ServiceException("message", originalException)) preserves the complete original stack trace as part of the new exception's own stack trace output, chained via getCause() -- without this chaining, the original exception's information (exactly where and why the underlying failure occurred) would be lost entirely, replaced only by the wrapping exception's own, potentially much less specific, stack trace pointing only to the wrapping/rethrow location.

public void processOrder(Order order) {
    try {
        paymentGateway.charge(order);
    } catch (IOException e) {
        // Wraps and preserves the original cause -- getCause() on OrderProcessingException returns the IOException
        throw new OrderProcessingException("Failed to process order " + order.getId(), e);
    }
}