Hi Zhongyuan.
You're right. Since all library functions are raising exceptions, there
is no need to translate an error number into a message. The exception
raised can itself have a number and a message. (The number can be used
when a DDU terminates. The message can be displayed by the DDU when it
terminates.)
The message is generated closer to where the error occurred when it is
included as part of the exception, so the message can be more
meaningful. For example, if an IO error occurred when trying to update
a particular file, the exception message generated can include the file
that triggered the error.
Using messages out of /usr/include/sys/errno.h is still best, for
consistency with other programs. Just prepend the file (or other cause
of the error) to the message.
So I think removing ddu_error_message() and making better use of
exceptions to propagate error messages is the way to go.
Comments?
Thanks,
Jack
On 09/16/09 00:55, zhongyuan sun - Sun Microsystems - Beijing China wrote:
> Hi Jack,
>
> I'm working DDU library API, please give me more detail about
> ddu_error_message() function. Other functions like ddu_devscan.....
> usually raise a exception directly not call this function. Hopefully you
> could create a use case for it especially used by AI.
>
>
