This is perfect because most of the time I don’t care about the logs but when I do, I don’t want to restart the app to enable logging. I also have an option to log to a file and I’ve recently added logging to a separate logging app via named pipe. My tiny logging module logs to a block of memory. When investigating issues it helps to know what sequence of events led to a crash. Trust me: there’s no amount of testing you can do yourself that would match all the different things that a thousand people will do just by using the app. I wrote wrote my own assert-like function which I enable in non-debug pre-release builds so that I automatically get bug reports from people hitting those conditions. If they’re not, something went wrong and you should investigate.
asserts are well established practice in C++ code: an additional code only executed in debug builds that verifies some conditions are true. Once you have crashes, look at them occasionally and try to figure out what went wrong and fix it On the server, process those files and generate web pages for easy viewing of the crashes. Briefly: setup exception handlers to catch crashes in the app, in crash handler download symbols from the server to get readable callstack, create a crash report that includes callstacks of all thread, program and os information, log and submit that to a server. Unfortunately it’s a pain to build but this is single most important thing you can do to improve quality of your software. Step through newly added code in the debugger, verify the newly added functionality works as expected and in general use the app a lot
0 kommentar(er)
