Quote Originally Posted by techgnome View Post
catch ex as Exception IS perfectly valid... yes, you SHOULD trap for known more granular exceptions and work your way down to more generic exceptions... but there are cases, where you jsut need to know an exception happened, log it, and move on... even if you trap for 20 specific exceptions... it's that 21st one that will get you... having a generic handler like ex as exception is good, providing you're doing something useful with it... and you're at the bottom level of the stack... I think exception handlers should be at the smallest level possible and that application-level ones are a sign of "I'm too important to go track through all my code and write proper error handlers where they belong.-tg
There's two issues here that should not be conflated. One is "catch the most specific exception you can deal with", the other is "never catch System.Exception".

What are you going to do with OutOfMemoryException? StackOverflowException? These ones are why you never catch System.Exception, it's related but not quite the same thing as catching the most specific exception you can.

Now personal preferences:
Catch only what you can do something with. Everything else, leave to bubble up and have an unhandled exception handler installed. (Although I think that might be what you were referring to with your "at the bottom level of the stack" comment?)
Fail fast - an exception you're not prepared for means your application is in an unpredictable state. Better to stop the application, potentially salvage what you can into a structure that the user can optionally recover from (a la Word) and then restart than keep on going potentially corrupting the users data beyond recovery.
Prefer checking that an operation is valid before performing it rather than relying on exception handling (the canonical example here is check a file exists rather than relying on FileNotFoundException).