nRF52840 SDK16 - Calling APP_ERROR_HANDLER after trying to send notifications

[Nikosant03]

Hi everyone,

I've noticed in some examples such as the ble_app_hrs that after trying to send a notification you check for some possible errors and then call  APP_ERROR_HANDLER.

if ((err_code != NRF_SUCCESS) &&
        (err_code != NRF_ERROR_INVALID_STATE) &&
        (err_code != NRF_ERROR_RESOURCES) &&
        (err_code != NRF_ERROR_BUSY) &&
        (err_code != BLE_ERROR_GATTS_SYS_ATTR_MISSING)
       )
    {
        APP_ERROR_HANDLER(err_code);
    }

Is this in general a good practice procedure after attempting to send notifications/indications?

Nick

[Karl Ylvisaker]

Hello Nick,

Is this in general a good practice procedure after attempting to send notifications/indications?

As a general rule, I would not recommend doing this kind of 'error filtering', where you only pass certain errors to your error handler - that kind of defeats its purpose of properly handling any error the application receives ( even if this handling is just jumping to the next step ).
In the particular case of the call to send notifications, there are however some errors that are more usual to encounter, and transient.
For example, the NRF_ERROR_INVALID_STATE is returned if the connection has been terminated or broken - this error is quite usual, since your notification may be triggered periodically by a timer, for example - and the termination can happen at any time, also in between having entered the timer_handler and trying to send the notification.
Another example is the NRF_ERROR_RESOURCES, which is returned if you attempt to queue too many notifications. The recommended course of action here is to wait until you have sent some notifications ( freeing up space in the queue ) and try to send the notification again.
You can see all this by checking out the notifying services' implementation. They usually have a couple of quick, fundamental checks at the beginning, before they proceed with the sd_ble_gatts_hvx call.

So, in general, I would say no - I would not advice anyone to do this in their production firmware. Instead, you should implement proper error handling in your app error handler.
However, for the specific case of notification sending I certainly see why this was added in the first place.
Going even further, I could definitely see the argument to keep it the way it is in the examples for the sake of clarity ( that these particular errors are somewhat expected, and temporary / non-fatal ). Without filtering these particular errors I think new users of the SDK in particular would see a lot more frustration, since the default app_error_handler is to reset the device for anything != NRF_SUCCESS.

I do not feel great about this answer - since it is not exactly clear cut - but I hope it at least clears up the reasoning behind those conditionals.

Best regards,
Karl

[Nikosant03]

Thank you Kalr for you effort!! I see the point!!

[Karl Ylvisaker]

It is no problem at all Nick, I am happy to help!

Please do not hesitate to ask if you should encounter any other issues or questions.

Best regards,
Karl