Exception handling is a tough topic to corral. I now work in a large development environment and even they have yet to formalize a standard exception handling methodology.


IMO, your code should reflect two things when considering exceptions:

1. Possible data entry
2. Possible data corruption

And the key word is obviously "possible". If you cover all possible entries (checking for type safety etc.) and then check for computational correctness then exception handling becomes very small in scale. This is the core. Find the exception. How you deliver it should be flexible. Log files, emails, bubble to the client and blue screen are all effective in getting the point across. (sarcasm on the bsod).

By no means am I an expert. And hardly a "seasoned" exception guru. But I follow this standard in all of my code. And some days it means I do hundreds of drivers for my objects with different data scripts until I find one that bugs out. Then I catch it, and start over. I like to think that if my applications actually get exceptions thrown (and they do without fail), I would hope to see what data caused it cause I will go to the source, add the catch and recompile.