« Corporate Cronyism | Main | A Little More On Exceptions »

July 27, 2006

Comments

ben

"accurate use of language is important to unambiguous communication" - I've been trying to explain that to an English major for 3 years. He claims that language is constantly evolving and we should not be upset when it does. I try to explain that if someone threatens to hit you if you don't give them your wallet, in a language you don't understand, you're going to get hit. And lose your wallet.

Regions are quickly becoming a great annoyance to me. While they can be very useful to the knowledgeable, I am constantly confronted with "regions" that encapsulate a single method, or, on the other end, entire classes. I personally believe that this Microsoft is at least partly to blame for not ever telling anyone (or at least, not publicizing) what regions should do. I know that thinking about the idea for a few minutes quietly will yield to anyone pretty much similar results... if that were commonly the case, you wouldn't have this blog, would you?

Finally, could you elaborate on the "unnecessarily handle exceptions" idea? I've got an idea of it in my head, but I'd like to be sure what you mean by it...

Overall, a great post, and something that would give at least a few people something to start with when thinking about standards and standards documentation.

Render

Language evolution:
Languages are constantly evolving *because* (among other reasons) people use them inaccurately. For instance, imagine a term, A, refers to complex concept "WXYZ". If you start using term A to refer to merely "XY", then you've got two situations: 1. you've probably created a term that is synonymous with an already existing term (unless the sub-concept "XY" is invalid/imaginary) 2. you've created a "referent hole", so to speak ... you've eliminated the term we needed to accurately refer to "WXYZ", and we'll have to come up with a new one. While this usually happens accidentally, through intellectual laziness, it has also been used intentionally. Concepts exist within a conceptual context ... a set of assumptions and relations that are valid when A referred to "WXYZ", and which are frequently not re-evaluated when A "evolves" to refer to "XY". Devious people will frequently use this effect.
--
Exceptions:
The methods I've seen recommended for using exceptions, and the techniques I prefer, require the following:
1. handle as many expected exceptions as cleanly as possible. By "cleanly" I mean in such a way that the application can meaningfully continue AND/OR change your application so that you reduce the possibility of the exception occurring in the first place (e.g., by doing input value validation earlier in the process.) The expected exception list is usually specified in the documentation describing the class.
2. if an exception is not such that you can handle it cleanly (or reasonably anticipate it), it is possible you'll want to reformulate or repackage the exception with qutie a bit more information so that the issue can be tracked down and, perhaps, a clean method of handling the situation can be applied in the future. This reformulation may be as simple as throwing a new exception with a different message (but don't forget to add the old exception as the innerexception value.)
3. Other than these situations, exceptions should not be handled anywhere but at the reporting level. There are habits that developers I've worked with in the past have had that actually reduce the amount of information being conveyed back. For instance, they might always put a catch block, and then rethrow the exception variable. The problem is, if you do (for example) "Throw ex" (where ex is the exception variable) MSIL actually does a new throw, which gives you a clean stack trace. If you just do "Throw" it will rethrow the exception in context and retain the stack trace. If you don't force the developers to always put a catch block, but instead put a finally block (you must have one or the other), it is less likely they'll inadvertently create this kind of situation.
4. if you are writing custom exceptions for any kind of remoting system, or a library that may be used in remoting context, be sure to make any custom exceptions serializable (and implement the 4 required constructors as well as, if necessary, the GetData call). Otherwise a custom exception will get repackaged as a simple System.Exception when it crosses the remoting boundary, and you can lose information.
5. There are features that various logging APIs have that can be useful, and you should examine and evaluate these as necessary. E.g., attaching context-specific properties to whatever the relevant CallContext wrapper is, so that that information can be logged as part of any exceptional, or even debug, event.)

The comments to this entry are closed.