Re: Public virErrorPreserveLast()/virErrorRestore()
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