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
I'm running into an issue where the library calls fatalError, killing my program rather than throwing an Error for me to handle. By throwing an Error, you allow the client to determine how best to deal with problems. In my case, I can continue with limited functionality even though I can't access GPIOs.
The text was updated successfully, but these errors were encountered:
I concur. I have a small weather station on a RPi2 using a couple GPIO sensors and a couple of I2C devices. It's been running fine for years but suddenly started crashing on launch due to a fault that developed in one of the I2C devices. SwiftyGPIO was calling abort() when it encountered an I2C error. I'd much rather handle this error, log it, and continue servicing the GPIO sensors.
I'm running into an issue where the library calls
fatalError
, killing my program rather than throwing an Error for me to handle. By throwing an Error, you allow the client to determine how best to deal with problems. In my case, I can continue with limited functionality even though I can't access GPIOs.The text was updated successfully, but these errors were encountered: