search

digitalbazaar / edv-client

An Encrypted Data Vault Client
BSD 3-Clause "New" or "Revised" License
13 stars 9 forks source link

Consider throwing an error for deleted documents on `get` #75

Open dlongley opened 4 years ago

dlongley commented 4 years ago

Currently, when retrieving a document via get, if it has been previously deleted, its meta information will include a deleted property. This issue is not about changing that meta property, but about considering whether or not the client should, by default, check for this property and throw an error in the get call.

If we decide to throw an error, we will need to choose between a NotFoundError or some kind of error indicating that the document is gone/deleted. We may want to differentiate for users of the library to eliminate confusion. However, the trade off is that code that checks for NotFoundError may also need to check for another error type.

Other considerations around whether or not we'd throw an error have to do with potential confusion around concurrent updates to documents. For example, if one party deletes a document just before another tries to update it, the latter will get a sequence error and may try again. This would result in getting a NotFoundError (or other) in the middle of their update attempt. We should decide if this is desirable or not. Either way, the deletion would have to be dealt with, so it seems throwing an exception in this case is probably cleaner.

Any other arguments for/against?

mattcollier commented 4 years ago

+1 to throwing an error, seems totally acceptable for someone updating a deleted document to get a NotFoundError. I'm not sure if errors here currently include any sort of details, but perhaps the fact that a NotFoundError is caused by the document being deleted could be surfaced to users somehow.