Using the Promises version of the API, any issues during initialisation aren't caught and surfaced as JS exceptions - this leads to the app using the lib crashing without being able to handle the error (e.g. in the case where you don't have a device attached...
bcm2835_init: Unable to open /dev/gpiomem: No such file or directory
[nodemon] app crashed - waiting for file changes before starting...
From taking a look at node-dht-sensor.cpp this looks like a simple case of the Execute override not checking for initialized == true before running Read(), so it attempts to read regardless of whether init was successful.
This makes the promise version of the call unusable IMO since there's no way to deal with initialisation errors. Using the synchronous version works as expected.
Using the Promises version of the API, any issues during initialisation aren't caught and surfaced as JS exceptions - this leads to the app using the lib crashing without being able to handle the error (e.g. in the case where you don't have a device attached...
From taking a look at
node-dht-sensor.cpp
this looks like a simple case of theExecute
override not checking forinitialized == true
before runningRead()
, so it attempts to read regardless of whether init was successful.This makes the promise version of the call unusable IMO since there's no way to deal with initialisation errors. Using the synchronous version works as expected.