How was it decided which methods should throw BackingStoreException?
Only the methods whose semantics absolutely require the ability to communicate with the backing store throw this exception. Typical applications will have no need to call these methods. As long as these methods are avoided, applications will be able to run even if the backing store is unavailable, which was an explicit design goal. • Why doesn’t this API provide stronger guarantees concerning concurrent access by multiple VMs? Similarly, why doesn’t the API allow multiple Preferences updates to be combined into a single “transaction”, with all or nothing semantics?? While the the API does provide rudimentary persistent data storage, it is not intended as a substitute for a database. It is critical that it be possible to implement this API atop standard preference/configuration repositories, most of which do not provide database-like guarantees and functionality. Such repositories have proven adequate for the purposes for which this API is intended. • Why does this API have case-sensiti
Related Questions
- We can declare methods that throw an exception (or error) of unknown type. Example (of method with type parameter in throws clause): interface Task< E extends Exception > { void run() throws E ; } Can such a method throw an object of the unknown exception (or error) type?
- Why only read() methods in ByteArrayInputStream does not throw IOException?
- How Do You Throw A Playing Card With Various Methods?
