我一直在阅读2013年4月推出的Event-Driven Message Programming Model，OnMessageOptions.ExceptionReceived Event，内置RetryPolicy（2013年5月，RetryPolicy.Default），{{3 （2011）已过时，等等（见下）。
我一直在监控通过消息泵收到的异常，以了解暂时性错误，我每天都会收到 MessagingCommunicationExceptions 。这The Transient Fault Handling Application Block（更新日期：2014年9月16日）推荐以下内容：
此异常表示可以表现出来的通信错误 当从消息传递客户端到服务总线的连接时 基础设施无法成功建立。在多数情况下， 如果存在网络连接，则可将此错误视为 短暂的。客户端可以尝试重试具有的操作 导致了这种类型的例外。也建议你 验证域名解析服务（DNS）是否可操作 因为此错误可能表示目标主机名不能 解决。
我的理解是，在版本2.1（2013）之后，没有额外的代码可用于处理服务总线上的瞬态错误。除非我的前提是错误的，为什么我每天都会收到瞬态错误？是否应忽略通过消息泵收到的异常？如果忽略，我只能假设意外的异常也会被忽略..我当然不希望这种情况发生。
Microsoft.ServiceBus的版本是2.4.0.0
也感兴趣：article，upgrading Windows Azure Service Bus from 1.x to 2.0 - Retry Policy，Introducing the Event-Driven Message Programming Model for the Windows Azure Service Bus，What's New in the Azure SDK 2.0 Release (April 2013)，What's New in the Service Bus 2.1 Release (May 2013)。
答案 0 :(得分：5)
正式回答here。简而言之，在重试尝试后，异常会出于监控目的而冒泡。长期：
从ExceptionHandler回调中获得的瞬态异常意味着 在重试尝试后，这些异常会被破坏。你应该 记录它以进行监控。如果需要，请采取行动。对于 例如，如果您的客户失去了您应该期望的网络连接 通过处理程序流出的大量通信异常。 在这种情况下，您可能需要采取适当的措施来解决问题。所以 问题的答案“我应该忽略它们吗？”真的取决于 条件。 - Serkant Karaca，微软