It's fine for me. Personally I don't think that you really want to show
any detailed error message to the user. Signatures and encryption
is a backend stuff. Most errors are total failures and you could not
recover from them. For example, in the situation you mentioned
the error case is applicaton bug since it gave template with DSA
signature and RSA key. User should not see this error message
at all and this is a bug in application logic. If you have any non-failure
problems (like signature validation failed) the function return success code
and the actual problem is described in the xmlSec*Result object
(where * is DSig or Enc).
However, I understand your concerns and I think there are few ways
to solve this problem:
1) Return *negative* error codes from functions (similar to your
suggestion). I kept this solution in mind when I did checks ret < 0
everythere :)
2) Some kind of "per-thread" error number (like _errno is c libraries).
3) Per-thread "error context" that holds information about error code,
error severity, location (function, line number), message, etc.
If you really want to have detailed errors then I would vote for option 3)
as the most general solution. However, I suggest to evalute the cost and
real requirements to have detailed error codes.
BTW, I would suggest to continue this discussion in the xmlsec library
mailing list so other guys can join us.
Aleksey.
dheitmueller wrote:
>Hello Aleksey,
>
>I have put aside the static linking issue for the moment, because it is an acceptable
>workaround for now to just dynamic link my binaries. I compiled the dsig2 example,
>but I used an RSA key instead of a DSA key. Naturally this failed, as the dsig2.c is
>hard-coded for a DSA private key.
>
>However, it may be worthwhile to rethink how the xmlsec library's return status codes
>work.
>
>It looks like a large number of the functions simply return zero or -1, which makes
>it quite difficult to do proper exception handling in conditions where there are
>multiple exit points for the function call (unless you have a debug binary, of
>course). Either way, the exception cannot be handled programatically (such as
>showing more user-friendly failure messages).
>
>Would you be willing to accept a patch that provides more detailed status codes as
>return values? We would substitute all the "-1" return values with more detailed
>error codes (which would be #defined and centralized into a single file). We would
>also need to modify any example code which checks for (return < 0) to check for
>nonzero returns instead.
>
>Of course, there are still functions in which the return value is not a status code.
>For the time being these will stay the same. However in the long term, perhaps it
>would be more uniform for all the library calls to use the same calling convention
>(returning a status code), which would require us to move the context presently used
>as the return value into an argument for all the relevant functions.
>
>Does this make any sense?
>
>Thanks,
>
>Devin
>
