Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Don't hard-crash when /dev/mem can't be opened #71

Open
helje5 opened this issue Jun 14, 2018 · 4 comments
Open

Don't hard-crash when /dev/mem can't be opened #71

helje5 opened this issue Jun 14, 2018 · 4 comments

Comments

@helje5
Copy link
Contributor

helje5 commented Jun 14, 2018

Currently you quickly run into a

Fatal error: Can't open /dev/mem , use sudo!: file ../.build/checkouts/SwiftyGPIO.git-1203819502/Sources/SwiftyGPIO.swift, line 353

when a tool is started w/o sudo.

Since that is so common, I would rather provide a proper API for that (probably something throwing an Error). The (user)-dev should handle that case, and provide a clean exit.

@uraimo
Copy link
Owner

uraimo commented Jun 18, 2018

Yeah, it makes sense when swifygpio is just used in a subsystem and the application should continue to work regardless of gpio failures.
I'll take a look at it, since GPIO objects are pre-initialized in the presets I'll likely turn those read/write methods into throwing methods and reorganize those checks.

@MotivDev
Copy link

MotivDev commented May 8, 2019

What is the status of this requested change? I would like to see something other than abort in the I2C module as well. I do not want to have my system taken down due to an I2C bus problem that impacts system functionality but it should not keep the remaining system components from operating.

Maybe it could return a Result type in its place which returns the data or an error depending on outcome?

@uraimo
Copy link
Owner

uraimo commented May 8, 2019

I will do a new release tomorrow or so and the refactor of the error handling will be one of the changes included 👍

@uraimo
Copy link
Owner

uraimo commented May 12, 2019

@MotivDev The next_release branch should already have what you need, for the original request of this issue I'll add and optional, and not really nice to look at, way to check if a GPIO/PWM is usable shortly.

Note: SPM should ignore the format of these -beta tags and use the last 2.0.0-??? tag if you set that release in your descriptor (if not, it's a bug).

Note2: This new branch contains other unrelated changes, so you'll likely need to update your code for them, sorry.

Note3: Use "2.0.0-beta2" as version tag (or whatever is the latest one) in your Package.swift ...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants