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
Rather than call abort() when an operation is unsuccessful, we should throw instead, so fault tolerance can be built into the library and callers can handle the error as they like.
The API could remain the same to facilitate backward compatibility, but variants of the exposed API would be added which contain the throws in their declaration. The existing API could simply call the new API in a try/catch and call abort() in the catch to keep existing functionality consistent.
The text was updated successfully, but these errors were encountered:
Hi! Yes, that's how it is/will be implemented in the next release (https://github.com/uraimo/SwiftyGPIO/blob/next_release/docs/1to2.md).
I've never merged because I planned to add a few more things but never had the time to think about them and I don't expect to have it anytime soon.
That being said, at this point I will align the next_release branch with the latest modification on the main branch and just release it.
Board Type
RaspberryPi3, but not relevant.
Operating System
Raspbian, but not relevant.
Swift Version
Pre-built 5.1
Description
Rather than call
abort()
when an operation is unsuccessful, we shouldthrow
instead, so fault tolerance can be built into the library and callers can handle the error as they like.The API could remain the same to facilitate backward compatibility, but variants of the exposed API would be added which contain the
throws
in their declaration. The existing API could simply call the new API in atry/catch
and callabort()
in thecatch
to keep existing functionality consistent.The text was updated successfully, but these errors were encountered: