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
In Util.js:338 the Mikronode library is listening for the process event unhandledRejection and parsing these rejections under the assumption that all events come from the Mikronode library. This makes issues like bitfocus/companion-module-bmd-hyperdeck#19 hard to debug.
Whenever a promise outside of the mikronode library is rejected but unhandled this listener will catch this. This is bad because the application developer loses control over how some parts of the application are handled and also because this listener makes the assumption a reason for rejection is always given. When this is not the case, the rejection handler in the mikronode library causes a new error because it tries to access event.cmd (where event is undefined)
A first course of action could be to add a check if event is defined before accessing any properties. E.g. changing line 139 to if (event && event.cmd) return;, this will at least not throw any new errors.
Ultimately the library should not handle process events at all in my opinion, as this should be done by the application itself and the library can make no assumptions about what other code will be running in the process.
The text was updated successfully, but these errors were encountered:
In Util.js:338 the Mikronode library is listening for the process event
unhandledRejection
and parsing these rejections under the assumption that all events come from the Mikronode library. This makes issues like bitfocus/companion-module-bmd-hyperdeck#19 hard to debug.mikronode/src/Util.js
Line 138 in 1575680
Whenever a promise outside of the mikronode library is rejected but unhandled this listener will catch this. This is bad because the application developer loses control over how some parts of the application are handled and also because this listener makes the assumption a reason for rejection is always given. When this is not the case, the rejection handler in the mikronode library causes a new error because it tries to access
event.cmd
(where event is undefined)A first course of action could be to add a check if
event
is defined before accessing any properties. E.g. changing line 139 toif (event && event.cmd) return;
, this will at least not throw any new errors.Ultimately the library should not handle process events at all in my opinion, as this should be done by the application itself and the library can make no assumptions about what other code will be running in the process.
The text was updated successfully, but these errors were encountered: