Software should not terminate itself on any error.
It must not modify any data in unclear application state.
Software should never leave the user unguided with a message such as 'Unknown error something-something'.
Do not terminate Except in Erlang/Elixir this is pretty easy. Catch all errors and if needed re-initialize the entire app to avoid an unclear state. Elixir apps terminate on errors. But typically a Cron job will restart them. It's similar to catch all errors and re-initialize, but it's managed from the outside. Not sure what is better, having disaster logic in- our outside of the app.
Do not modify That is, I think, the hardest and toughest requirement. Mapping data structures between SQL stores, JSON stores, Key-Value stores and so forth has the potential to miss some state changes, which can happen while mapping data - mapping needs time and state changes over time!. Before saving any data, the app should re-evaluate. But it's a trap because while evaluating another state can change. We cannot stop the world. Strategies like eventually consistent can force developers to program more defensively but it's not guaranteed like ACID. Saving data ACID in a multiparadigm environment must be ensured by the application. Save, check, roll-back, repeat until all the checks pass. Think of Ethernet network collision detection.
Do not leave users behind Catching errors in switch-case like constructs is easy. But never use the default branch to report 'unknown error.'. Sony does a clever trick in their Playstation SDK. For catching errors in a switch-case block, they use a default unknown error template. But while compiling, a Marco replaces all of those templates with a unique ID calculated by the inheritance structure and or package structure. Users will always see an error code. Developers will always know where the error was caught. It's not a holy grail but it's much better than what we typically see everwhere else.
Denny Trebbin
Lead Fullstack Developer. Experimenting with bleeding-edge tech. Irregularly DJ. Hobby drone pilot. Amateur photographer.
Good question.
I think,
Do not terminate Except in Erlang/Elixir this is pretty easy. Catch all errors and if needed re-initialize the entire app to avoid an unclear state. Elixir apps terminate on errors. But typically a Cron job will restart them. It's similar to catch all errors and re-initialize, but it's managed from the outside. Not sure what is better, having disaster logic in- our outside of the app.
Do not modify That is, I think, the hardest and toughest requirement. Mapping data structures between SQL stores, JSON stores, Key-Value stores and so forth has the potential to miss some state changes, which can happen while mapping data - mapping needs time and state changes over time!. Before saving any data, the app should re-evaluate. But it's a trap because while evaluating another state can change. We cannot stop the world. Strategies like eventually consistent can force developers to program more defensively but it's not guaranteed like ACID. Saving data ACID in a multiparadigm environment must be ensured by the application. Save, check, roll-back, repeat until all the checks pass. Think of Ethernet network collision detection.
Do not leave users behind Catching errors in switch-case like constructs is easy. But never use the default branch to report 'unknown error.'. Sony does a clever trick in their Playstation SDK. For catching errors in a switch-case block, they use a default unknown error template. But while compiling, a Marco replaces all of those templates with a unique ID calculated by the inheritance structure and or package structure. Users will always see an error code. Developers will always know where the error was caught. It's not a holy grail but it's much better than what we typically see everwhere else.