David:
I am updating the java bindings. Should I still us the return value to
determine if the call was successul, or use this new method api?
-- bk
On 09/21/2009 08:48 PM, David Lutterkort wrote:
This change has been long overdue: API functions to inquire about errors
and details about them. The function aug_error can be used to get an error
code for whatever error made the last aug_* fail.
This functionality is now used by augtool to print error messages, for
example,
augtool> print "/*[1 = 'foo']"
error: Invalid path expression
error: type error
error: /*[1 = 'foo']
That's a lot friendlier than typing 'print /augeas//error' all the
time. The main advantage though is that Augeas is easier to use as a
library now, since you can use the result of aug_error to see if a call
failed because of an invalid path expression (probably a bug in your
program) or because of a failed malloc.
There's still a lot to be done to make error reporting perfect, but this is
a decent start.
Note that some calls will always return success even if some aspect of them
failed. For example, aug_load will tell you it succeeded even if some files
could not be loaded - that's necessary both for API compatibility, and
makes good sense. For analyzing the result of aug_load, you still have to
look at /augeas/files//error.
One thing I am debating with myself is if the API should implicitly do an
'rm /augeas//error' for every call. IOW, error nodes would only stick
around up until the next call to a aug_* function. The current behavior
(they stick around until the user removes them) seems to make the API
harder to use than it has to be.
David
_______________________________________________
augeas-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/augeas-devel
_______________________________________________
augeas-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/augeas-devel
