You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Both at the client and service side we should add type checking of method arguments and return values
(This is related to #97 which was specifically about properties)
Client method arguments, emitting signals: trying to use a string instead of an integer, or the other way around, will raise an exception before the bus sees the wrong type, but the exception is an implementation accident. It should be an explicit
type A was expected but type B was seen, in argument foo
(the the method and interface names will be easily seen from the backtrace)
Client return values: not trying to catch confused/malicious services for now
Service method arguments: this should be avoided by client libraries paying attention to introspection data and doing their own type checking (see (1)), but it is relatively easy to send a mistyped call. Here an example of passing an integer where a string is expected, the caller gets to see an exception caused by the wrong type:
TODO: find a well known error name+format for type errors
Listening for signals: what if someone sends a mistyped signal? Could be even pretty easy if the listener filters only on interface and not a well-known sender
Properties.Set with a wrong type: I know I said this was about methods, not properties, but I think this check is still missing :-(
Service return values: similar to (1)
The text was updated successfully, but these errors were encountered:
Both at the client and service side we should add type checking of method arguments and return values
(This is related to #97 which was specifically about properties)
Client method arguments, emitting signals: trying to use a string instead of an integer, or the other way around, will raise an exception before the bus sees the wrong type, but the exception is an implementation accident. It should be an explicit
(the the method and interface names will be easily seen from the backtrace)
Client return values: not trying to catch confused/malicious services for now
Service method arguments: this should be avoided by client libraries paying attention to introspection data and doing their own type checking (see (1)), but it is relatively easy to send a mistyped call. Here an example of passing an integer where a string is expected, the caller gets to see an exception caused by the wrong type:
TODO: find a well known error name+format for type errors
Listening for signals: what if someone sends a mistyped signal? Could be even pretty easy if the listener filters only on interface and not a well-known sender
Properties.Set with a wrong type: I know I said this was about methods, not properties, but I think this check is still missing :-(
Service return values: similar to (1)
The text was updated successfully, but these errors were encountered: