Expose error name for MessageBus.invoke() errors #2
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
♻️ Current situation
MessageBus.invoke()
takes a callback, the first argument of which is the error encountered, if any, and the remaining arguments are the return arguments of the D-Bus method call. Per the D-Bus spec, messages of typeERROR
are described as follows:Additionally, these messages must have an
ERROR_NAME
header field, which is a string that indicates the type of error they represent.Currently, if an error occurs,
MessageBus.invoke()
passes the return arguments, and not the error name, to the callback. The upshot of this is that the callback receives only the user-friendly explanation of what went wrong, not the machine-usable error type.💡 Proposed solution
This changes the behavior of
MessageBus.invoke()
to, when an error occurs, invoke the callback passing as the first argument an object that looks like this:⚙️ Release Notes
MessageBus.invoke()
orMessageBus.invokeDbus()
, the first argument passed to the callback (err) is now an object containing two keys:name
is the D-Bus error name, andmessage
is what previously was passed in as this argument.➕ Additional Information
See homebridge/HAP-NodeJS#980 (comment)