Error handling seems too restrictive
Error handling as defined in the spec (which is only a draft by the way) seems to me too limited. There are already two error codes that have been added to Tumbler that were not there: TUMBLER_ERROR_NO_CONTENT
and TUMBLER_ERROR_SHUTTING_DOWN
.
But most importantly, I find that the error signal is missing a parameter: the error domain, passed as a second parameter to g_set_error()
. This is to allow Tumbler to directly forward errors coming from third party APIs it uses, without having to translate or aggregate them to fit into its own error codes.
This is actually how error handling has been done in plugins for a long time, so that on output, the client is not sure what the error code of the signal corresponds to. An important example is the case of a cancelled request that results in an error signal: one needs to be able to identify with certainty the G_IO_ERROR_CANCELLED
code, which is only possible with the G_IO_ERROR
domain.
Obviously, this would make the existing client codes incompatible with the new error signal, and we would be out of the spec. But who implements this spec besides Tumbler?
If we don't want to go that way, we'd have to rethink the error handling of all plugins, to make them return only the error codes of the spec, and especially no error on cancellation.