CLR and .NET 1.1

I am currently reading a book, among others, titled “Accelerated C# 2008” by Trey Nash published by Apress.  When I read a technical software book I try most of the examples shown.  Due to this I take longer to read this type of book.

Trey Nash is an Escalation Engineer at Microsoft working on the Windows operating systems as well as various other products.

At this point I do not have much to say of the book as a whole, but something I read called my attention.  Chapter seven “Exception Handling and Exception Safety” has a section titled “Changes with Unhandled Exceptions Starting with .NET 2.0”.

Page 165 describes how the .NET 1.1 designers of the CLR (Common Language Runtime) decided that it would be a good idea (it went out to production) for threads to fail and just disappear without providing any feedback to the user or developer.

Over a couple decades ago I created a software development methodology named CDP (short for Cyclic Development Process).  That methodology described among many other things, how to structure software while coding in the C programming language which was (and still) one of the best languages that have come around in the past few decades.  When developing any function / method a returned value is set to zero (0) to indicate that all is well.  As the function / method is populated, failures return a negative code and jump to the done (exit) label.  After performing all the cleanups needed by the function, the function would return with the negative value that indicated the original issue.  This approach can be seen like a waterfall / cascade.

The process would repeat until the code would reach a point in which the software had to exit to avoid corruption of data or the software could continue at some point without inconsistencies.  The decision is always left to the developer.  The methodology just addresses the default behavior.

If you look a modern object oriented languages like Java, C++ and C# (just to mention the most popular) the concept they use is identical to the one described by CDP.  The frame of each method unwinds going back to the entry point of the application.  If at any point in the iterative process a handler for the exception is encountered, action is taken.

What was interesting to see is how such a major flaw in design of the CLR could have gone into production?  Worse yet, how could such approach that would certainly produce unstable applications could have been considered by Microsoft, which is one of the largest, and probably most reputable software developer in the world?

Perhaps Microsoft needs to hire some experienced software engineers, which could bring to the table besides knowledge, some sense to younger and inexperienced developers fresh from graduate school.

Be Sociable, Share!

Leave a comment

Your comment