You can't. If your code causes a crash the OS just kills you. It won't risk your misbehaving code running on. So the best solution is don't crash. Being serious if you know your code can crash work out where and why and fix it. Don't ever ship code with known crashing bugs.
Also don't write garbage into the cache. Check the quality of what you're writing before you write it!
Personally I'd want the cache to persist across application runs: it'll make the application seem faster and better over time.
Of course, I would never send up a code with known problems and my app does not crash if I do not create errors in my code to provoke crashes. I just wanted to be sure that if some problem occurs later on which I havent thought about, the app will behave allright... Perhaps that is over kill...?
I check errors and handle them through the app and that might be enough?
I also agree on the cache and the app being faster. The problem is that I do not have any chance to know when and what in the data being updated. It is done by someone else and an img could (of course it wont be like that irl) be updated once a year or onci in a minute.. This forces me to start with an empty cache everytime the app is running. Timestamps does not help me in this case. But caching the img during the app run is atleast better as letting the user wait for the download of each and every img on app-start or to get the img everytime the user would like to look at it...
MACloop