I am very happy to have this book done!   Ever since I started working on the CLR, almost 6 years ago, I have wanted SOMEONE to do a book like this.  In a past life when I did Java development, I really liked Chan (et al)’s The Java Class Libraries, Volume 1 and I wanted a similar book covering the BCL.   At the time I didn’t think I would be the editor. This book could have never come together without significant help from a large number of folks.  I will not repeat the book’s acknowledgements here, but know that it is more their work than mine.

 

So, consider this the first plug for the .NET Framework Standard Library Annotated Reference Vol 1 (I think this needs a shorter name, how about SLAR)?

 

This book is based on the text from ECMA\ISO CLI and C# standards.  In addition, we included a number of features to make it valuable to the average developer. 

Samples – Over 1,000 additional samples showing how to use the APIs (all available on the CD)

Annotations – Personal comments from key members of the BCL design team.  These were fun and therapeutic for us to write.  I hope when you read them you get a sense for the personalities inside the BCL team as well as some insights into what we did well, what we could have done better and how best to use what we produced. 

Poster and Diagrams – We show clearly and visually how the BCL is put together. 

“C# Header file” view of each type – This is exactly the view we use when we are designing and reviewing types internally, so we thought it would be useful to developers as well.  We also indicate which members are not in the .NET Compact Framework, those that were introduced in V1.1 of the .NET Framework and those that are not part of the Standard.

 

Over the next few months, my intention is to share some of that content with you on this blog.  I am not trying to turn this blog into an ad for the book.  In fact, I don’t even get royalties on the thing.  My goal in writing the book and this blog is the make developers on our platform happier and more productive.    Although if you do buy a copy or two it will help my case to produce volume II, update for Whidbey\Longhorn, etc.

 

Here is the first type in the book and a couple of annotations:

 

 

public class ApplicationException : Exception

{

        // Constructors

        public ApplicationException ();

        public ApplicationException (string message);

        public ApplicationException (string message, Exception innerException);

MS CF   protected ApplicationException (SerializationInfo info, StreamingContext context);

}

 

 

KC - Designing exception hierarchies is tricky. Well-designed exception hierarchies are wide, not very deep, and contain only those exceptions for which there is a programmatic scenario for catching. We added ApplicationException thinking it would add value by grouping exceptions declared outside of the .NET Framework, but there is no scenario for catching ApplicationException and it only adds unnecessary depth to the hierarchy.

 

JR - You should not define new exception classes derived from Application-

Exception; use Exception instead. In addition, you should not write code that

catches ApplicationException.