Closed ueno closed 4 years ago
Existing error codes can be somewhat abused (EINVAL
for invalid parameters, EPERM
for a verification failure), but we may indeed need more specific error codes.
I agree; it's worth considering defining your own error type(s) and avoiding $errno
altogether.
Different libraries use vastly different approaches. I guess we don't need a system that is as complex as OpenSSL's error queue, but errno
is likely not precise enough.
The signature PoC implementation defines a couple error types already.
These are a little vague and incomplete, but the exact set of errors we need is probably something we can figure out while writing actual implementations.
Doing it the other way round (trying to figure out what we will need without any concrete implementation) seems a little bit risky.
As more functions were implemented, in became pretty obvious that many domain-specific error types were indeed necessary.
In the proposed witx API, we currently use
errno
to indicate any kind of error (typicallyerrno.inval
). In the crypto context it would be helpful if there is a way to propagate the actual error cause (e.g., decryption/verification failure).