啊…旧的异常处理/重新连接难题。
有些传输提供程序将为您自动重新连接您的应用程序，而另一些传输提供程序使应用程序驱动器重新连接。通常，重新连接对应用程序隐藏异常。不利的一面是，如果 所有
远程消息传递节点都关闭，则您不希望该应用程序永远挂起，因此最终，您 必须 包括一些重新连接逻辑。
现在这是有趣的部分-
您如何以提供者中立的方式处理异常？JMS异常几乎毫无价值。例如，“安全例外”可能是Java安全策略限制太严格，文件系统权限限制太严格，LDAP凭证失败，与传输的连接失败，队列或主题的打开。失败或其他数十种与安全相关的问题。链接异常具有传输提供程序提供的详细信息，可以真正帮助调试问题。我的客户通常在这里采用三种不同的方法之一…
- 对待所有错误相同。关闭所有对象并重新初始化它们。这是JMS可移植的。
- 允许应用检查链接的异常，以区分致命错误和瞬时错误（即，身份验证错误与队列已满）。提供商不可移植。
- 提供程序特定的错误处理类。其他两个的混合体。
在您的情况下，队列和主题对象可能仅在原始连接的上下文中有效。假设提供程序自动重新连接，那么您会收到异常的事实意味着重新连接失败，并且无法还原队列和主题对象的上下文。关闭所有对象并重新连接。
是否要做一些更特定于提供程序的操作（例如区分暂时错误和永久错误）是“取决于情况”的事情之一，您必须根据具体情况加以解决。
