Axel Dörfler schrieb:
Ingo Weinhold <ingo_weinhold@xxxxxx> wrote:This is not an obscure corner case. AFAIK all storage kit class setters are destructive and render the object invalid when they fail (most have an InitCheck() even). So, while I agree that in a new API it would be nicer to have these BPath methods work differently, it's not even inconsistent as it is now. Nor it is particularly annoying -- one can just use the API as documented.Why would you want to break a well documented and existing API that almost all apps use?I'm not even sure that it would be a good idea to keep the object in a sane state after such a failure - after all, it definitely is not in the state you would want it to. If you don't care and just continue to use it, you would probably not access the file you originally intended to -- letting all subsequent actions fail as well seems to be the preferred thing that should happen.Of course one could change the setters to be non-destructive in case of failure, but I don't really see any benefit in doing so. If you still need the original object as is, you would need to copy it before, anyway.
Yeah, that makes sense. Best regards, -Stephan