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