`qubes.exc` – Exceptions¶

As most of the modern programming languages, Python has exceptions, which can be thrown (raised) when something goes bad. What exactly means “bad” depends on several circumstances.

One of those circumstances is who exactly is to blame: programmer or user? Some errors are commited by programmer and will most probably result it program failure. But most errors are caused by the user, notably by specifying invalid commands or data input. Those errors should not result in failure, but fault and be handled gracefuly. One more time, what “gracefuly” means depends on specific program and its interface (for example GUI programs should most likely display some admonition, but will not crash).

In Qubes we have special exception class, qubes.exc.QubesException, which is dedicated to handling user-caused problems. Programmer errors should not result in raising QubesException, but it should instead result in one of the standard Python exception. QubesExceptions should have a nice message that can be shown to the user. On the other hand, some children classes of QubesException also inherit from children of StandardException to allow uniform except clauses.

Often the error relates to some domain, because we expect it to be in certain state, but it is not. For example to start a machine, it should be halted. For that we have the children of the qubes.exc.QubesVMError class. They all take the domain in question as their first argument and an (optional) message as the second. If not specified, there is stock message which is generally informative enough.

On writing error messages¶

As a general rule, error messages should be short but precise. They should not blame user for error, but the user should know, what had been done wrong and what to do next.

If possible, write the message that is stating the fact, for example “Domain is not running” instead of “You forgot to start the domain” (you fool!). Avoid commanding user, like “Start the domain first” (user is not a function you can call for effect). Instead consider writing in negative form, implying expected state: “Domain is not running” instead of “Domain is paused” (yeah, what’s wrong with that?).

Also avoid implying the personhood of the computer, including addressing user in second person. For example, write “Sending message failed” instead of “I failed to send the message”.

Inheritance diagram¶

Module contents¶

Qubes OS exception hierarchy

exception qubes.exc.BackupAlreadyRunningError(msg=None)[source]¶

Bases: QubesException

Thrown at user when they try to run the same backup twice at the same time

exception qubes.exc.BackupCancelledError(msg=None)[source]¶

Bases: QubesException

Thrown at user when backup was manually cancelled

exception qubes.exc.DeviceAlreadyAssigned[source]¶

Bases: QubesException, KeyError

Trying to assign already assigned device.

exception qubes.exc.DeviceAlreadyAttached[source]¶

Bases: QubesException, KeyError

Trying to attach already attached device.

exception qubes.exc.DeviceNotAssigned[source]¶

Bases: QubesException, KeyError

Trying to unassign not assigned device.

exception qubes.exc.DeviceNotFound[source]¶

Bases: QubesException, KeyError

Non-existing device.

exception qubes.exc.PermissionDenied[source]¶

Bases: PermissionError

Raised deliberately by handlers to inform the request is prohibited.

The request is valid, but the client does not have permission to perform the operation. Clients in dom0 should usually not get this error. It must only be raised by “admin-permission” events. In HTTP, this would be 403 Forbidden.

exception qubes.exc.ProtocolError[source]¶

Bases: AssertionError

Raised deliberately by handlers to indicate a malformed client request.

Client programming errors. The client made a request that it should have known better than to send in the first place. Includes things like passing an argument or payload to a service documented to not take one. The only way that a correctly behaving client can get ProtocolError is qubesd is either buggy or too old. In HTTP, this would be 400 Bad Request.

It should not be used to reject requests that are valid, but which qubesd is refusing to process. Instead, raise a subclass of QubesException with a useful error message.

exception qubes.exc.QubesBackupProfileNotFoundError(msg=None, profile=None)[source]¶