Re: Signals, GErrors and Introspection

On Sat, Feb 19, 2011 at 12:04:54PM -0500, Colin Walters wrote:

> While I know there are some examples of GObject libraries using GError
> in signals,

Would you mind pointing me to these examples? Just out of curiosity.

> I think it's a bad idea even without bindings being
> involved, because signals are designed to allow multiple connections,
> but that doesn't make sense in this situation even in C.
> You can design the API so that a GError is a return value from a
> callback, or design the API so that callers need to implement an
> interface or subclass.

You’re mixing two very different things here: one is the fact that you
think signal handlers should not allowed to report errors using GError,
the other one is the fact that you believe using signals in my specific
case doesn’t make sense.

Regarding the first point, I can’t see why it wouldn’t be reasonable to
provide signal handlers with a way of returning a detailed error message
to the caller, instead of a simple success/fail value.

Regarding the second point, I am aware that multiple handlers connected
to an I/O signal make no sense, that’s why I’ve used a custom accumulator
which allows only the first connected signal handler to run.

I could rewrite the API using callbacks, but the result would be IMHO
less nice; besides, I’m not sure how well callbacks work when crossing
language boundaries, while I know that signals play it nice. Don’t get
me started on using subclasses or implementing interfaces to provide this
kind of functionality: it’s simply too much work from C.

> I'd prefer we try harder to avoid using GError in signals than hack
> this in.  This would be another case where we have to step outside the
> GType system, which gets into pain.

I’m all for remaining inside the boundaries of GType. It’s where I feel
most confortable myself ;)

> Also not a big fan of introducing a totally different exception API.

Neither am I, really. But I feel the current error reporting API, while
adequate most of the time, is not perfect and could use some improvement.

As I already said, it would probably be possible to build the new API
around GError, but making sure the old API and the new one can cohexist
is a job for someone way smarter than I am.

Andrea Bolognani <eof kiyuko org>
Resistance is futile, you will be garbage collected.

Attachment: signature.asc
Description: Digital signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]