I don't think it's Microsoft, specifically, saying 'thou must use structured exception handling!'.

Structured exception handling has been a tried and true method of handling errors before Microsoft was born; it may not have looked like it, but it was.

The issue is the VB never had it - then it did. I can telly you, I was a tough convert to it, but now I have seen the benefits. But, that isn't the mantra...the new mantra is that: 'thy program shall never cause an error!'

I stick by this - If your program causes an exception handler to fire, you have done something wrong (true, there area few areas where you have little choice to use an exception handler - file handling is an example).

There is a prevalence in the programming world to allow exceptions to 'bubble up' to the caller; I believe this promotes laziness and results in pretty crappy programs with obnoxious dialog boxes. It's a viable technique in a very few circumstances. However, if you are only performing mathematical calculations there is absolutely zero reason an error should occur. Zero. None.

But I, like 100.0% of all other people who program, are lazy. If you think you aren't then I hope someone else is scrutinizing ones code. Because I know I'm lazy, and I make mistakes, I have a global exception handler (and, hopefully, a handler for every thread I create). If that handler ever fires, it means I messed up.

Additionally, and exception handler should be used at the absolute smallest level of granularity - it's actually very lazy to just wrap a whole file writing routine in an exception handler. The larger the error handler span, the potentially larger the 'types' of errors that could occur, and the more difficult it is to generate a meaningful error message - thus most programmers don't. We end up with 'object or with variable not set' error message boxes. Arrgh!

Basically, an Unstructured exception handler does the exact opposite of what's required: wrappers large chunks of code (out of necessity, since it's actually more difficult to create fine granularity unstructured error handling); pretty much ignores most errors; allows for sloppy coding because the error handler catches and often continues, hiding the poor coding (You don't use mahogany for your cabinets if you are going to put a pine laminate on top).