Should FDS return code be checked after event not after call

[dgerman]

The examples include checking the return code from various FDS calls immediately after the call.

Only some errors can be detected at the time of the call (for example NULL arg, Not initialized, unaligned address)
It seems that others must wait until the operation is complete ( especially if more than one operation has been queued) as per the callback event which makes this example misleading.

Can you clarify this?

For example WRITING A RECORD:

rc = fds_record_write(&record_desc, &record);

if (rc != NRF_SUCCESS)

{

/* Handle error. */

}

"The command is queued up, and the success or failure is indicated through event callbacks."

https://infocenter.nordicsemi.com/topic/sdk_nrf5_v17.1.0/lib_fds_usage.html

[Einar Thorsrud]

Hi,

You are right that there are different errors you can get returned from FDS calls and as events (callbacks), so you need to check both. This is the case with most asynchronous API calls in the nRF5 SDK. I did not get what was misleading in which example though, nor what you need clarification on. Can you elaborate?

[dgerman]

Thank you for the clarification about both kinds of errors and the timing.

The example shows only testing the return code immediately after the call and does not show any indication that other errors may occur which will NOT be detected by this code segment example.

Perhaps including a delay, testing for the operation to complete  before checking the return code and/or including the callBack handler testing the return code would warn users not to depend on only testing the return code after the operation call.

[Einar Thorsrud]

Hi,

Ah, I see. This example print a log on any error, which is probably what you want in such an interactive application. Specifically, look at the beginning of fds_evt_handler() from <SDK 17.1.0>\examples\peripheral\flash_fds\main.c:

static void fds_evt_handler(fds_evt_t const * p_evt)
{
    if (p_evt->result == NRF_SUCCESS)
    {
        NRF_LOG_GREEN("Event: %s received (NRF_SUCCESS)",
                      fds_evt_str[p_evt->id]);
    }
    else
    {
        NRF_LOG_GREEN("Event: %s received (%s)",
                      fds_evt_str[p_evt->id],
                      fds_err_str(p_evt->result));
    }

You could argue that the color for errors could be something other than green, though...

For a real application you probably want to do something more than just logging that an error occurred, but how to handle an error is application specific (sometimes you may want to ignore it, other you may want to try again, or do something differently altogether).

[dgerman]

Thank you for additional clarification and example.

I think it is very important that the example be modified to consider post-call error checking.

[dgerman]

https://infocenter.nordicsemi.com/topic/sdk_nrf5_v17.1.0/lib_fds_usage.html