logging to help debug and user experience

4.24: adda/architecture/logging to help debug and user experience:
12.20: summary:
. logging of calls can tell you where an error occurs;
when errors are out of your control .

. in order to formally prove your code,
you start with functional decomposition,
and then you are checking user input
so then given there is expected input
you can make assertions about the
input you are feeding to your subroutines .
. so your internal subroutines
(the ones getting their input from
one of your other subroutines)
don't have to check their input
unless you are worried about platform corruption:
if malware could corrupt your memory
then internal subroutine input checks
would make sure your program always
closed with a friendly message
instead of a crash reported by the OS .
. if you can't formally verify your program
such as when relying on 3rd party libraries
that could crash because they are buggy
then you need to know when your program is crashing
and what it was doing when it crashed .
. some OS's might be able to restart your program
and inform it that it is recovering from a crash,
if not then you need to be logging each library call
and log when you closed normally,
so then on each startup you check the log:
if log is not ending in "closed normally"
then it crashed because of the previous call,
so look at which is the last logged call
and start logging the inputs of any calls to that routine .
. if it happens again,
then ask user to email you a report
showing the problem call
and optionally also send the problem inputs,
(if they care to check the data is not sensitive).
-- it might not depend on the inputs anyway:
its crashes could be due to not being functional
or using the OS incorrectly sometimes .