GNOME Bugzilla – Bug 643787
GDBus client, generated C doesn't compile if a client (interface) method doesn't throw any error
Last modified: 2018-02-12 09:12:26 UTC
Created attachment 182350 [details] [review] codegen: GDBus client, warn when an interface client doesn't throw error A simple code like this doesn't compile due to some references to the unset "error" pointer. [DBus (name = "com.example.TestService")] interface Demo : Object { [DBus (name = "emitHelloSignal")] public abstract string emit_hello_signal (); } However valac doesn't check this, and so there's just a C error: pyclient.c: In function ‘demo_proxy_emit_hello_signal’: pyclient.c:275: error: ‘error’ undeclared (first use in this function) pyclient.c:275: error: (Each undeclared identifier is reported only once pyclient.c:275: error: for each function it appears in.) error: cc exited with status 256 Compilation failed: 1 error(s), 0 warning(s) With this patch, now any interface method is checked for throwing an an error. If no erorr is thrown, then a valac warn is shown and the code is compiled without try/catch error support (just passing NULL instead of error). I preferred to just use a warning and then fix the code to be used without errors... However, we also could use a more restrictive (and simpler) implementation that forces always to declare dbus interface methods that throws errors; if no throws is found for a method, the valac compilation would fail.
*** Bug 638693 has been marked as a duplicate of this bug. ***
*** Bug 647033 has been marked as a duplicate of this bug. ***
Created attachment 185515 [details] Sample I also noticed that you can't register an object that implements a DBus interface. dbus_test.vala:19.9-19.55: error: DBusConnection.register_object requires type argument with [DBus (name = ...)] attribute conn.register_object ("/org/example/demo", obj); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Compilation failed: 1 error(s), 0 warning(s) I have to explicitly set the type of KlassA to Scanner.
That's expected. You can use conn.register_object<Scanner> ("/org/example/demo", obj) as an alternative to changing the declaration of 'obj'. register_object in GDBus registers the object for exactly one interface. If your object implements multiple D-Bus interfaces you have to execute register_object multiple times, once per interface. To avoid ambiguities and inconsistencies, we require that the generic method register_object is called with the right type instead of implicitly checking for possible suitable interface implementations .
Given it does not work without throwing the error, why not report an error then bail out instead of reporting a warning?
It works without throwing the error. With this patch we warn that a throw statement should be added, but otherwise the GError value is set to NULL.
Bump, I'm confirming this issue still exists in 0.15.2: [DBus (name="com.some.dbus.name")] interface anInterface: Object { public abstract void doSomething(); } void main() { anInterface i = null; try { i = Bus.get_proxy_sync(BusType.SYSTEM, "com.some.dbus.name", "/com/here"); } catch(Error e) { } } gives: VALAC test_vala.stamp test.vala:5.5-5.36: warning: method `anInterface.doSomething' never used public abstract void doSomething(); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Compilation succeeded - 1 warning(s) gmake[1]: Leaving directory `/home/benjsc/work/synrgic/MTTPrep/SynTapEnvironment/src/applications/apitest' CC test-test.o test.c: In function 'an_interface_proxy_doSomething': test.c:115: error: 'error' undeclared (first use in this function) test.c:115: error: (Each undeclared identifier is reported only once test.c:115: error: for each function it appears in.) test.c: In function '_dbus_an_interface_doSomething': test.c:134: warning: unused variable 'error' gmake: *** [test-test.o] Error 1 Vala 0.15.2
(In reply to comment #0) > With this patch, now any interface method is checked for throwing an > an error. If no erorr is thrown, then a valac warn is shown and the code > is compiled without try/catch error support (just passing NULL instead of > error). > > I preferred to just use a warning and then fix the code to be used without > errors... However, we also could use a more restrictive (and simpler) > implementation that forces always to declare dbus interface methods that throws > errors; if no throws is found for a method, the valac compilation would fail. Just passing NULL doesn't fit well with Vala's error handling. If we want to support client methods that do not throw errors, we should implicitly catch the error at runtime and log a critical warning. This would follow the approach we take for method calls outside a try-catch.
(In reply to comment #7) > Bump, I'm confirming this issue still exists in 0.15.2: > > [DBus (name="com.some.dbus.name")] > interface anInterface: Object > { > public abstract void doSomething(); > } > > > > void main() > { > anInterface i = null; > > try { > > i = Bus.get_proxy_sync(BusType.SYSTEM, > "com.some.dbus.name", > "/com/here"); > > } catch(Error e) { > } > } > > > gives: > > VALAC test_vala.stamp > test.vala:5.5-5.36: warning: method `anInterface.doSomething' never used > public abstract void doSomething(); > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Compilation succeeded - 1 warning(s) > gmake[1]: Leaving directory > `/home/benjsc/work/synrgic/MTTPrep/SynTapEnvironment/src/applications/apitest' > CC test-test.o > test.c: In function 'an_interface_proxy_doSomething': > test.c:115: error: 'error' undeclared (first use in this function) > test.c:115: error: (Each undeclared identifier is reported only once > test.c:115: error: for each function it appears in.) > test.c: In function '_dbus_an_interface_doSomething': > test.c:134: warning: unused variable 'error' > gmake: *** [test-test.o] Error 1 > > Vala 0.15.2 Bump, I stumble upon this problem using 0.20.1 with my own dbus client code and the test example above. Adding throws DBusError to the abstract interface method's solves the issue. I took me some while to pinpoint this issue and this bug report, this should definitely be solved in any way so a new user like me don't end up in this dark corner.
*** Bug 744482 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of bug 779652 ***