将异常记录移至Exception过滤器是否具备独特价值？

我刚阅读了《A New Pattern for Exception Logging》一文，若该模式成立，这种做法似乎合理。但我发现Exception处理器中可获取传入参数（我仅记录此类参数），且使用throw;语句也能抛出完整堆栈信息。那么我是否忽略了关键要点？将异常记录移至Exception过滤器的优势究竟是什么？

博客核心示例代码 #

try
{
    Divide(13, 0);
}
catch (Exception e) when (False(() => _logger.LogError(e, "Unexpected error.")))
{
    throw;
}

博客核心观点（翻译） #

当抛出异常时，运行时会在调用堆栈中搜索匹配的异常处理器。运行时会遍历堆栈，检查每个catch块是否与异常匹配（比如异常类型匹配）。找到匹配的处理器后，堆栈会展开到该位置并执行catch块。

这个行为的关键在于两个独立步骤：查找，然后展开。

...

关于异常过滤器需要牢记的关键点是，由于它们挂钩到流程的“查找”阶段，这意味着它们在异常抛出的位置运行，而非捕获的位置。这起初有点难理解，但逻辑是合理的：异常过滤器在堆栈展开前运行。

核心优势解析 #

• 完整保留原始堆栈上下文：throw;虽能保留堆栈跟踪，但catch块记录日志时堆栈已展开，日志里的堆栈是捕获位置的上下文。而过滤器在堆栈展开前执行，能记录异常抛出时的完整调用堆栈、局部变量等原始现场，这对多层嵌套调用的故障排查至关重要。
• 避免日志重复记录：多层catch块若都加日志，易出现同一条异常被多次打印的情况。过滤器仅在“查找匹配处理器”阶段执行一次，无论后续有多少匹配的catch块，都不会重复触发日志，保证日志唯一性。
• 无侵入式捕获逻辑：过滤器记录日志不会改变原有catch块的业务逻辑，无需在每个catch里写重复日志代码，也不会干扰异常的正常捕获和抛出流程，保持代码整洁。
• 精准记录异常触发场景：外层catch块可能无法获取深层函数抛出异常时的局部变量或上下文参数，而过滤器运行在抛出点的上下文，理论上可访问异常抛出时的所有局部状态，让日志包含更精准的故障触发信息。

内容的提问来源于stack exchange，提问作者David Thielen