为什么 nodeExists() 会抛出 BackingStoreException

Question

简单的问题：我想知道为什么Preferences 方法nodeExists() 会抛出必须捕获的BackingStoreException？究竟是什么导致了BackingStoreException，在Preferences API 中的所有方法中，为什么此方法（而不是所有其他方法）需要捕获它？

从Preferences API 文档中阅读这一段对我没有多大帮助：

从 Preferences 对象读取首选项的所有方法都需要调用者提供默认值。如果先前未设置任何值或后备存储不可用，则返回默认值。目的是允许应用程序运行，尽管功能略有下降，即使后备存储不可用。一些方法，如flush，具有在后备存储不可用时阻止它们运行的​​语义。普通应用程序应该不需要调用这些方法中的任何一个，这可以通过它们被声明为抛出 BackingStoreException 的事实来识别。

也许我不明白，但是后备存储的不可用不会对所有Preferences 方法构成风险吗？上面的段落让我觉得我在调用一个我“不应该调用”的方法。然而，检查节点是否存在对我来说似乎是一种常见的操作。

每次我调用nodeExists() 时，我都必须在其周围添加一个try / catch 块并处理异常。

Answer 1

nodeExists 可以抛出BackingStoreException，因为它需要访问后备存储以确定节点是否存在。您通常不需要先验地知道节点是否存在，因为调用node(pathName) 或静态*NodeForPackage 将在需要时自动创建它及其祖先，我原以为这将是更常见的模式首选项 API 客户端的操作 - 使用各种 get 和 put 方法获取“您的”节点（如果需要，创建它）以及在节点中存储和/或加载值。

获取节点的方法（node、userRoot 等）不会抛出 BackingStoreException，因为如果后备存储不可用，它们仍然可以通过给你一个空节点来继续.该节点上的任何get 调用将简单地忽略后备存储中的值并为您提供您提供的默认值，并且任何put 调用将无法持续存在（除非在刷新节点之前后备存储再次可用） .首选项 API 只是一个“尽力而为”的系统，旨在通过返回默认值而不是抛出异常来尽可能优雅地降级。