On 03/26/2012 10:59 AM, Kevin Wolf wrote:
Am 26.03.2012 17:38, schrieb Anthony Liguori:
You can add parameters to Errors in a fully compatible fashion, so just add an
filename parameter to PermissionDenied. Problem solved.
So your error types will end up accumulating optional parameters for all
contexts in which they can occur?
In the long run, PermissionDenied would have an optional file name (for
raw), optional host name, port, sheepdog volume ID (for sheepdog),
optional source and destination block devices (for blkmirror), remote
host and port, local address and port (for UDP chardevs)...
I don't see the generalization.
I could go on forever. Does this really make sense?
What's the alternative proposal? If you just add errno to OPEN_FILE_FAILED,
then you end up with errors for SHEEP_DOG_ATTACH_VOLUME_FAILED,
NBD_CONNECT_FAILED, etc.
The proper way to design an error is to make it a verb, and have parameters that
correspond to the direct object and/or indirect object. The subject is implied
by the command itself.
So in the case of block_snapshot_sync, the failure is:
The block_snapshot_sync command failed due to insufficient permission when
creating foo.img.
So the error is "PERMISSION_DENIED", with the data "filename=foo.img"
In the case of NBD, the error would be:
The block_snapshot_sync command failed because the host localhost:42 could not
be contacted.
The error is "CONNECTION_REFUSED", with the data "hostname=localhost,port=42".
It the block layer returns both of these as EACCESS today, then this is a good
argument to refactor the block layer to take an Error object instead of
overloading the meaning of EACCESS.
Regards,
Anthony Liguori
Kevin
