Just a question: Now to test of new GPIO pin assignment fails? about onoff

[johntalton]

if the line fails, consider filing a bug report / issue. If it is a permission issue, sharing troubleshooting helps others. If its a system level restriction or other non-library related issue it helps expand the collective knowledge. And in the case is a defect or better error reporting / behavior, that may have a future as a PR into this lib :)

(some opinion):

• Testing for construction is usually a code smell.
• And try/catch-ing breaks some best practices but mainly, is confusing to developers (though commonly used)
  Constructors should return this object regardless. And provide and isValid-like method for testings construction state.
  (end)

TL;DR; ya, try / catch at some level will solve things 🤦‍♂️

There are also guards that can be used. Gpio.accessible (static method on class - aka, can be called before any new) ... will attempt to test the basic access levels needed for this library to function (though, it does't say that it will succeed later, just that the core interface (sysfs) /sys/class/gpio/export is available to the running process (aka, can we call sysfs gpio/export write number).

A test like this only provides a useful guard for system that do not process a /sys/class/gpio or even device tree itself (...windows, and some container/vm restrictions etc).

Constructor Behavior

The Gpio constructors normal throw path is related to permission:

onoff/onoff.js

Line 157 in 07d36e2

constructor(gpio, direction, edge, options) {

makes a call into waitForGpioAccessPermission which add addition construction time constraints (access to the gpios specific sysfs files).

Which eventually can throw:

onoff/onoff.js

Line 73 in 07d36e2

throw e;

There are other theoretical exceptions that can plague constructors also ... Buffer.alloc

A TypeError will be thrown if size is not a number. NodeJS Buffer

though you have a better chance at winning the lottery.

A control parameter gpioPreviouslyExported:

onoff/onoff.js

Line 81 in 07d36e2

gpio, direction, edge, options, gpioPreviouslyExported

can be used to alter the behavior within limited scope (reducing the need for the current runtime to need access to the sysfs gpio/export. This requires coordinated orchestration between consumers however (but can also be used to subvert systems that apply restrictions on the export and / or also add user permission into).

A more comprehensive accessCheck has been considered / discussed but likely falls a bit outside scope. There may be space for an npm helper module. SysFsAccess or some such, but a library as such would spill into the non-gpio land quickly as a generic solution and add bulk to this lib.

In practice

The odds are, permission or miss-configuration is the likely issue. Guarding against this at the Gpio level is likely too fine grained and should be moved into an application-setup phase. For other error, allowing them to bubble (by not adding try/catchs) up to the application layer is likely the correct logic.

Wrapping them in Promises can also provide a standard catch workflow that can be useful.

Other errors that exist around the Epoll dependency and unsupported system. This usually manifests itself as a require(onoff) related exception, though it can also cause a undefined exception when trying to use the class.

As an aside, no try/catch specific blocks are usually added to code I write, allowing for the highest level application to execute proper fallback handling or error. 10 out of 10 times, the error has been configuration or logic error on my end :)

[Nodi-Rubrum]

Wow, thanks for the great detail. Since I am developing for Node Red, I usually setup a try/catch wrapper around any library calls or dependencies, this is more to isolate exceptions from the parent Node Red framework, which is a best practice, since a node failing should not be allowed to crash Node Red. I have not yet used Promise methodology (much) in that I am new to Node(js) or JavaScript, but the concept I do understand, so as I develop more elegant code, I plan to move towards more Promise leveraging.

[fivdi]

@johntalton Thank you for providing all the useful feedback.

@Nodi-Rubrum I'll go ahead and close this issue as I think all the required information has been provided.