Currently, verify_object has been implemented without a return value and solely throws an exception if the checked values don't match what's found in the the object metadata. Given its expected use to be only after storing an object with just a stream, it seems intuitive to also delete the object when a mismatch occurs.
This simplifies the clean-up process for the calling client, since the only files that need to be removed at this point is the object itself (tag_object is not called since exceptions are thrown, so the reference files do not exist).
Alternatively, verify_object could also return a boolean, allowing the client to decide whether to delete the object or not. However, this means that delete_object needs to be refactored to handle this scenario.
Currently,
verify_object
has been implemented without a return value and solely throws an exception if the checked values don't match what's found in the the object metadata. Given its expected use to be only after storing an object with just a stream, it seems intuitive to also delete the object when a mismatch occurs.This simplifies the clean-up process for the calling client, since the only files that need to be removed at this point is the object itself (
tag_object
is not called since exceptions are thrown, so the reference files do not exist).Alternatively,
verify_object
could also return a boolean, allowing the client to decide whether to delete the object or not. However, this means thatdelete_object
needs to be refactored to handle this scenario.