Friday, October 23, 2009

Chapter 1 -- Error Handling


3 4



Chapter 1



Error Handling



Software developers at times view proper error handling as a distraction and treat it as an afterthought. This approach is unfortunate. I have witnessed developers investing person-weeks and months in the resolution of failures that would have taken just minutes to diagnose, had the original developer used error detection and propagation to anticipate the particular failure mode in only the most generic fashion. Or consider this: when was the last time you received an error code like "0x8004024C" with absolutely no description and had only a vague idea where to start looking for its meaning? Proper and complete error handling is essential for shrink-wrapped components, and also tremendously enhances the maintainability of any software project in the long run. Always remember that the developer who runs into a failure from your component six months down the road might be you.



The generation of distinct error codes and context information benefits the caller of COM+ interface methods and properties in these general ways:




  • It protects a caller from choosing inappropriate code paths, thus preventing more severe failures.


  • It can inform a caller of the particular way in which a call succeeded (when success codes are used).


  • It provides a caller with an opportunity to choose a code path, based on the distinct value of the error code, which can remedy the failure condition.


  • It provides a human-readable description of a failure, and perhaps even a help file reference, to the developer of the calling code or to an end user. The generating interface's GUID and the implementing object's ProgID can also be returned. This information is valuable while debugging, but can also be used by end users or Information Services (IS) staff to report bugs to support line personnel or development groups.





All this power and flexibility make the COM+ error-handling model somewhat complicated. The top two reasons developers shy away from correct error-handling procedures do not include laziness; rather, they are confusion regarding the rules and mechanisms of COM+ error handling, and the lack of a planned and coherent approach that can be applied throughout the project. Removing these two obstacles to using effective COM+ error handling is the goal of this chapter.



No comments: