Quote:
@Brian: I use exception handling where I should: File access, web access etc. I don't use it to handle programming errors such as divide by 0 or writing outside of a block of allocated memory. They will - and should - cause the program to crash to I'm forced to fix it, which leads to better software in the end. Although I could probably replace crashing by displaying a popup. Anyway, when I worked at Philips it was actually quite common in cases where you got into a situation that should not occur to just write: *(int*)(0) = 0; - causing a hard crash. We're talking about software used during medical operations etc! Of course this causes program to crash - but in the end you get better software because you have to fix all the crashes. Instead of hiding them and just hoping that nothing else will break as a result.
I'm not really sure that is the best way to handle things. If you're in a situation that "should not occur", to be able to do anything at all, you have to know that you have arrived at something that should not occur.
From your perspective, what is wrong with the following?
Try
{ Try Code block
}
Catch (exceptions) // At first, all exceptions via (...). You could refine it to specific exceptions over time as needed.
{ Catch Code block // Includes code to write various things to a log file or submit the log via internet, and clean up and shut down gracefully.
}
This would unload the app gracefully and would not hide anything. Yes, you'd want to limit the number of try/catch blocks to code that is more fragile, or else it would start dragging down performance.
You could add in a "Submit Crash Reports" option into the application, which would then enable you to add a call stack reporter functionality in the Catch block. Just over the past day, I submitted a crash report to Mozilla for something that happened in Firefox when it prompted me to do so via a handler like what I described.