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

[macOS] Catch exceptions that happen in the bluetooth thread, for example when rfcomm channel can't be opened #32

Closed
semvis123 opened this issue Feb 13, 2021 · 1 comment · Fixed by #34

Comments

@semvis123
Copy link
Contributor

Currently it fails to catch the error that happen when it connects for example.
This is because the connection happens in a different thread, when the recoverableException is thrown from that thread, it doesn't get catched and thus crashes the client.

This could be solved by passing an error handler to the bluetoothConnector, but I can't get that to work.
My approach was to have a void that gets defined in MacOSBluetoothConnector::MacOSBluetoothConnector, but that gives an error at compilation: Reference to non-static member function must be called .

Used code:

// macosbluetoothconnector.mm
MacOSBluetoothConnector::MacOSBluetoothConnector(void (&errorCallback)(RecoverableException))
{
    this->errorHandler = errorCallback;
}
// macosbluetoothconnector.h
private:
    void *rfcommDevice;
    void *rfcommchannel;
    std::thread* uthread = NULL;
    void errorHandler(RecoverableException);
@Plutoberth
Copy link
Owner

Plutoberth commented Feb 15, 2021

You can solve this using std::promise. You can create an std::promise<void> in connect, take its future, and then move it into the new thread. In the new thread you can set it with nothing or an exception as needed. Back in connect, get it to wait until the promise is resolved and propagate the exception if one was set.

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

Successfully merging a pull request may close this issue.

2 participants