On Thu, Dec 14, 2023 at 12:18:27PM +0100, Peter Krempa wrote: > While I have no problems with virErrorPreserveLast() as that's just > syntax sugar on top of existing public functions, I don't think that > it's a good idea to expose virErrorRestore() as that gives the access to > previously unexposed virSetError(). This gives the users possibility to > set arbitrary errors due to the error struct being public as noted > above. This sounds very much like a "don't do that then" scenario. > Saving an error to a custom error object should be enough and I don't > really see a point in making libvirt carry it around with the > possibility of it being overwritten at any point by another library > call. I'm not very clear on your suggestion. If I can't restore the libvirt error in the error callback, how would the eventual API call return have the right error? Are you suggesting I have to have custom logic to save the error to some thread-local location, and change every single API call handling to look there, ignoring the API return value and error object? Or do you have a suggestion I'm missing that is more elegant than this? I think it's pretty illustrative that the library itself uses these calls everywhere. regards john _______________________________________________ Devel mailing list -- devel@xxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxx
