Using Stg_get() and Stg_set()
|Top Previous Next|
Extensive use of the stg_sg() can quickly bloat your project because of all this result checking that you must do everywhere you call stg_sg(). Fortunately, there is another way, but do exercise caution with it — see details below.
Stg_set() and stg_get() do not return the execution result directly. Instead, they invoke callback_stg_error() whenever any error is detected. This procedure then can be a catch-all point for setting-related errors in your project. Here is an example:
Notice how readable and simple the code above is. You simply read and write settings, and when some error happens, you handle it in callback_stg_error(). Since this is a single place for handling setting errors, you usually include some dramatic code there... something equivalent to the "blue screen of death" in old Windows.
A sobering note — think when it is OK (and not OK) to use stg_get() and stg_set(). Typically, "it is not OK" when the setting is being written to after some sort of user input. Let's say the user is editing settings via a web-browser interface. He makes a mistake and inputs an invalid new value for the setting. If this part of your code relies on stg_set() then this simple user mistake will lead to the halt of device operation, which is totally unwarranted.
So, as a rule of thumb, use stg_set() and stg_get() "internally", in places where incorrect user input can't cause errors. In places where user input is processed use stg_sg(), which will allow you to check execution result "right there" and respond to the user if there was an erroneous input.
We use the same approach in our own sample project.
One additional fact about the stg_get(). Not only does it invoke callback_stg_error() whenever there is an error, but also returns the default value of the setting (defined with the setting configurator) when possible. This way, if the setting can't be read, you get its default value and your reliable product can continue operating somehow.