kick #2

Here I'm continuing what I've started the last time. Coding: technical aspects, part #1 Everyone knows, there are best practices for handling exceptions. One of the design guidelines for exception-handling says: "Avoid handling errors by catching non-specific exceptions, such as System.Exception, System.SystemException, and so on, in application code." That's a great piece of advice (yes, you can never handle all the exceptions), as long as you don't use .Net Framework (.Net FW). One reason for this is you never know for sure which types of exceptions can be raised by the code (MSDN or intellisense not always help here, believe me, I've dug though some call stacks pretty deep just to get the exception types). There are other problems: 1) invoking same methods can produce different types of exceptions in different versions of .Net FW (see how the Mutex class behaves in v1.1 and v2.0). So if you're writing anything forward-compatible (that's you're planning to move to the next FW version someday), you'll have to retest every piece of Framework code for exceptions before actually migrating to the new FW. So some developers prefer catching non-specific exceptions and then filtering irrecoverable exceptions and throwing them no matter what -- this breaks another design guideline which says "Do not exclude any special exceptions when catching for the purpose of transferring exceptions". BTW, MS guys themselves do love filtering exceptions. 2) .Net FW throws exceptions of type System.Exception (WMI is written particularly badly and does just that in many places) -- how I'm supposed to _handle_ this ugly stuff in a nice way, I wonder? Therefore, most of the time we, developers end up either filtering exceptions by type (by throwing only some of 'em) after cathing the most general System.Exception or even worse -- not filtering and just catching. It's just impossible to do proper exception handling at a 100% in .Net FW at the moment. I see only one way through this mess: make all developers decorate every method with attributes which tell what types of exceptions the method throws (throwing SystemExceptions or just Exceptions must be prohibited).