Handle the possible different exceptions when an application tries to establish a session but an error is thrown #12
Conversation
This commits doesn't adds functionality, just add the cases for the new EstablishSessionStatus values added in the previous commit and add a TODO mark to not forget to implement it correctly in the example
…n throws an exception TODO: review how to handle the possible errors. TODO: confirm the possible errors with flutter_ble_lib_ios_15 and flutter_blue_plus * It is just a possible way to handle the errors. * The ideal would be to have some standardized response to catch the exceptions, * But it must be confirmed.
|
I was thinking about the alternative idea I commented in the main message of the PR. In the case we check that there are different exceptions, as I think it is, depending of the bluetooth package used, what if we implement a necessary catch function that must throw an In Future<EstablishSessionStatus> catchConnectedSessionStatusError(Exception error, StackTrace stackTrace)So instead of We could return something like: } catch (error, stacktrace) {
if (await transport.checkConnect()) {
return transport.catchConnectedSessionStatusError(error, stacktrace);
} else { Then the developer who implements the package have the responsibility to adapt it to the current behavior of its package and, in case it has specific exceptions for that, it can also be implemented. The minimum necessary implementation could be something simple as: Future<EstablishSessionStatus> catchConnectedSessionStatusError(Exception error, StackTrace stackTrace) => error.contains('Null') ? EstablishSessionStatus.keymismatch : EstablishSessionStatus.unexpectederrorIt is just an idea, but while I was writing I was losing a bit of confidence on it, because of how are currently handled the exceptions in the try block and because I think I mix some facts and data, because the origin and what are the messages of the exceptions can be are a bit confusing. Let's see in another comment to not mix. |
|
We could also simplify and adjust to the current flow of the try loop: And incorrect proof of possession can be detected by checking if the response is if (response.isEmpty) {
// Here it could return another exception like `EstablishSessionStatus.wrongbufferlength` if we achieve it is the only reason for this condition
throw Exception('Empty response');
} else if (response == Null) {
return EstablishSessionStatus.keymismatch;
}And finally in the if (await transport.checkConnect()) {
return EstablishSessionStatus.unexpectedstate;
} else { |
|
@ivanhercaz can you verify to me if the package flutter_blue_plus give us some error code like "// I/flutter (21772): BleError (Error code: 401, ATT error code: 4, iOS error code: null, Android error code: null, reason: GATT exception from MAC='XX:XX:XX:XX:XX:XX', Or some similar to this error message? the error code 401 indicates an authentication problem, so we can give the error to the developer based on this error code So we can do somethin like that : we can improve this code later, this is just a test code we have to find something in common that the Bluetooth packets will return, so we can standardize it for the developer @ivanhercaz I made a request on LinkedIn too, there we can exchange contacts and communicate better to talk about the future of the package |
Hi @ogabrielinacio! Excuse me, I have been very very busy and now I am bit ill with cold hehe. I don't usually use LinkedIn, I use more Telegram (same as here, like ivanhercaz), I also have Signal too in case you prefer, but if you want, you can send me an email to ivan@corujadigital.tech and I will share with you my user. I will try to take a look to everything as soon as possible but I can't promise a date 😿 |
Yes! Flutter Blue Plus (FBP) and any stable bluetooth package must implement at least the handling of the existent and possible GATT errors. FBP has a list of the possible errors on Android and iOS and descriptions for each one, take a look. Just a note, error code
Oh! I see, you catch the first number then return it. The problem I see with that is that the package would suppose that the first number is the error code, but we still have to adapt it to different cases. For example, in the case of FlutterBleLib for iOS 15 the exception returns a
From both,
In the case of FBP we have
This code is the same as the
In summary FBP returns a string with the next format So if we apply the regexp we end with a
Totally agree about that... What about just returning the exception in case it isn't one of
It may be not the best option, but what I am thinking it is that we are trying to match possible errors that are handle in a different way by each bluetooth package, so maybe, as What do you think about it? Of course, we could write a section or even a guide with some notes about possible errors and how to handle them in known bluetooth packages. |
I have though more about it: the unique related errors with the If there is another error that it isn't related directly with the In that case we would have that a specific The main problem I see here is that if we log the exception message that was thrown, but we also wants to allow the users to handle by themselves the error in their implementation we must return the value and the error thrown, maybe something like: But that will require to change the signature of the |
|
Okay... Now I see by you said the This happens when a wrong POP is introduced... It is a characteristic failure but as we know there is a wrong POP, we associate it with an authentication error. In this case we can wait and deep more in how we manage the session establishment or we can return a It has been really hard to find the correct way to handle this situation. |
|
I am reviewing it again, but checking the ESP32
This And, for example, in the And this And many of its values, if not all, seems related to possible responses of a ESP32 when trying to establish the session. Then, if we check the generated Dart files from the If we look for It is possible to see there is a And, after all this research and checking better how works a session, how it is defined and more, I think the approach of this PR may be... completely wrong. Because, after all of this, I think we should first handle all this possible states during and after establishing a session with the ESP32. It doesn't seem something hard to implement but it will require time and, probably, even more time for testing all the possibilities. What do you think, @ogabrielinacio? I think we should rethink a bit the |
ivanhercaz
added
type/bug
2 participants
EstablishSessionStatus.keymismatchis always returned when the session can't be established, even if it isn't because a wrong proof of possession. It is reported in #11 and this PR tries to handle this situation.TransportBle.Tasks
keymismatch.flutter_ble_lib_ios_15andflutter_blue_plus).Errors detected
All this errors currently returns
keymismatch, the first one is the correct one, the rest of them must have their specific value.Incorrect proof of possession
Tested with
flutter_blue_plus, not tested with the example of this package.Must returns the
EstablishSessionStatus.keymismatch.With correct proof of possession
Tested with
flutter_blue_plus, not tested with the example of this package.What must be returned? An
EstablishSessionStatus.unexpectederroras a generic error without more information?Wrong MTU/buffer length
This exception also returns a
KeyMistmatch. It happens when MTU is increased over 512. I am usingflutter_blue_plusand512is the default MTU in theconnect()method, although I think it isn't a specific issue of that package and it may happen with any other Bluetooth plugin.It must be researched more. It may return something like
EstablishSessionStatus.wrongbufferlengthorEstablishSessionStatus.mtuerror.Alternative idea
Thinking about the complexity of catching this errors, as mentioned in the second point of the introduction of this PR, an alternative may be to return a generic error that the user must catch according to the bluetooth package used in the
TransportBle.