Closed rm5248 closed 5 years ago
I'm not so sure that it would be a good idea to allow 'null' as interface.
The reason why an interface is always expected is that the DBus spec says that signals must have an interface defined in the message header and one usually want to listen for a specific signal using a signal handler.
In case of the signal handlers, the code a bit further down will fail with NullPointerException.
Also the variable passed in to the handle() method of the interface will receive null... Maybe there are more places where values are not checked for 'null' I'm not aware of yet.
Anyway, I don't know any other method than adding more if-statements to that already long list of if-statements.
Since the interface can never be null when sending, there's no way we can have a NullPointerException. This basically just allows you to match *
for the interface, e.g. you don't care what the interface is, but you may care about what the member name is.
PR #65 contains my proposed changes.
I cleaned it a bit and merged your PR.
With some of the previous arbitrary signals improvements, it's now possible to send and receive signals. This works fine for most use cases that I've encountered so far, but I've found a new use case where I'm only interested in listening to a signal with a type, member, and object(e.g. the
AddMatch
method to the DBus-daemon istype='signal',member='mymember','path=/'
. In code, this isnew DBusMatchRule( "signal", null, "mymember", "/")
) This results in no callbacks being called, as the code for handling this assumes that there is always an interface.I was considering adding a new block to the if statement(something like this:)
However, this seems like it could easily get out of hand given the possible combinations of parts of the signal that could be null(4! = 24). Is there a better way to do this, or should I simply add some more statements to this block?