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