Welcome to the GDNet C# Workshop – Ch. 12, 16, & 17
For a complete introduction to this workshop, please look here.
Workshop Overview
This workshop is designed to aid people in their journey to learn beginning C# (C-Sharp). This workshop is targeted at highly motivated individuals who are interested in learning C# or who have attempted to learn C# in the past, but found that without sufficient support and mentoring they were unable to connect all the pieces of this highly complex but powerful programming language. This is a 'guided' self-teaching C# workshop. Each student is responsible for taking the time to read the material and learn the information.
Additionally, this workshop does not attempt to defend C# as a language, nor does it attempt to demonstrate that C# is either more or less useful then other programming languages for any particular purpose. People who intend to start a discussion about the differences between C# and ANY other languages (except as are relevant to a particular discussion), are encouraged to do so elsewhere. This workshop is for educational, not philosophical discussions.
Finally, the community and tutors that arise out of this workshop are here for making the learning process run more smoothly, but are not obligated to baby-sit a person's progress. Because everyone will be working from the same references (
.NET Book Zero and optionally the C# Language Specification
1.2 &
2.0), students may find it easier to get answers to the specific questions they might have. There is no minimum age requirement, and there is no previous programming experience required. However, we will be moving quickly so it's essential that students stay on task and dont fall behind.
Experienced C# Programmers
Feel free to post your own additional knowledge about the topics, however please try and keep the information you provide objective. If you MUST provide subjective/opinion-based information, please do so by marking the paragraph with
[opinion] tags. This will make it clear to the readers what is fact, and what is opinion. Also, it may be relevant to mark some information with
[observation] tags for information which you’ve “observed” but may not be fact. Finally, if you’re providing information which is related to common programming errors, you might tag it with a
[warning] tag. Also, feel free to post links to additional resources about the topics for this week. I will do my best to add those to the “Additional Resources” section at the bottom of this post.
Quizzes & Exercises
Each week I will post 'quiz' questions and exercises in the weekly thread. Please try and answer them by yourself. Once you've done so, feel free to look over the answers provided by others and submit your own answers if you've not yet seen them posted. Discussion about the quiz questions and answers is encouraged for clarification. Finally, experienced C# programmers may feel free to post quiz-like questions and exercises of their own.
Chapters 12, 16, and 17
Introduction
Welcome to week 5 of the C# Workshop. This week we’ll take a step back and look at structured exception handling for a moment before moving forward. I decided to postpone exception handling until week 5, rather than doing it in week 4, because I felt that some of the items covered in the book after exception handling were actually more important. And, I wanted to make sure everyone had all the required tools in their toolbox before we concluded Project 1.
Additionally, exception handling is one of those very powerful tools that not everyone knows how to use. In fact, very few do. Ever heard the phrase “give a child a hammer and the whole world becomes a nail.” Well, exception handling is very similar. You see, structured exception handling is designed to separate out the responsibility of detecting an exception, from that of processing and responding to an exception. This is especially important in Component Oriented Programming. In CoP, the goal is to develop small, light-weight components which can be used as the building blocks for larger, language-independent applications. However, this is only possible if there’s very little coupling and cross-talk between the components, otherwise, how would I easily be able to take one component and use it somewhere else, if it depended upon five other components.
Now, with the requirement to limit coupling the need to separate the detection of exceptions and the handling of exceptions becomes even more vital. If each component is responsible for detecting exceptions and handling exceptions, it requires the component to do far more work than it is intended to, and makes it inflexible. It’s not uncommon for a component to generate an exception which in one case should be treated one way, while when included in another project may be treated differently – or entirely ignored. As you can see, if the exception handling was integrated within the component, this situation would become much less possible. Instead, these types of exceptions should be treated differently by the consumer of the component, once the component has detected the exception exists and thrown an error.
But…and this is a big butt. There is a difference between exceptions, and just negative cases. Negative cases are things which are not opportune for the flow of execution, but aren’t really exceptional, unexpected situations. For example, lets say I ask a person to input their name into a textbox. Once they do, I want to make sure the name they entered is formatted correctly. Ie, my system may not allow names with numbers, and it may not allow names with spaces. So I must validate the name. This is usually a routine called “Validate” or something similar and involves making sure data is appropriate for use by the rest of the application. If in the process of validating I encounter the data is formatted incorrectly I have two options.
1. I can throw an exception. In this case I’m saying…”uhh, data’s formatted incorrectly but I don’t know what to do about it. Someone else needs to handle it. Here - ::Toss:”. This response is suitable if the class that’s validating the data isn’t directly responsible for interacting with the name system. In other words, if the process of dealing with names isn’t local to the validater. This is typical if the code that is designed to process the name is actually in another component. This is also suitable if you suspect that names might have different rules in different places. For example, you may not allow spaces in character names, but you might want to allow spaces in pet names, but you’d like all other rules to apply, and would thus like to use the same validator. In this case, you might just detect a space, and thow an exception, then if the caller wants to ignore the exception, they can.
2. The other option is handle the exception locally. This is like saying “uhh, data’s formatted incorrectly, but I understand what and why the data is wrong. I understand that data of this type is treated the same way throughout the entire system, so I’ll just deal with it myself.” In this case, the validator may make changes to the formatted data such as remove the spaces, numbers, etc….It may also return a code of some type to the caller which indicates the success or failure of the validation. If the return code says it failed in some way, then the caller can let the rest of the system know that the data was incorrectly formatted and move forward. In either event, the actual handling of the invalid data is handled by the same component, and often by the validator itself. This is simply local, logical handling of invalid, yet not “exceptional” data.
The basic rule of thumb is, if you can easily anticipate a user or data behaving in a predictable, yet undesirable way, and it’s something that can be handled locally, then it should be handled locally. However if there’s a chance something will occur, putting the data into an exceptional state, and which shouldn’t happen except in unusual circumstances – or if there’s a situation in which the handling of the exception may be different in different circumstances, then don’t handle it locally, and instead throw an exception for the caller to catch and process.
Ok, now that’s I’ve gone on my little rant about exception handling, lets move forward. The next chapter in the book we’ll cover deals with equality. The key thing to note here is that classes and structs deal with equality differently, and it’s not always obvious what they mean by equal structures and equal classes. The bottom line is that value types are equal if all the data they contain are equal. Reference types, however, are by default only equal if the references they contain point to the same place in memory. This means that, by default, class objects which contain the exact same data but are located in two different places in memory, will not be seen as equal when using the equality operator. Fortunately, C# makes this easily fixable by allowing us to override the equality operator for custom classes.
And the final part of this week’s material is on Properties. These are the chewable, chocolaty, goodness that makes C# truly an elegant language. You see, public fields are a quick and dirty way to allow users of your class to gain access to your data. However, doing so exposes your implementation and thus reduces encapsulation. This makes it more difficult to change your implementation later. As well, by exposing your fields as public it makes it infinitely easier for your objects to be put in an inconsistent state as there’s no guarantee that validation of data will happen before the fields are set to invalid data.
In contrast, hiding your data behind methods which can then ‘get’ and ‘set’ your private information is messier, but it allows for validation and encapsulation. But all those parentheses running around can often get cumbersome and difficult to work with. On top of which, calling a method to obtain data violates the basic rules of object oriented design. As we’ve talked about previously, methods are supposed to represent what an object can DO, while fields represent the characteristics about an object. So a method which returns data about the object really doesn’t make any sense, as the method isn’t DO-ing anything.
Properties are C#’s answer to that object oriented design problem. Properties are simply methods which allow encapsulation and validation, and yet look like and behave like public fields to the caller, keeping with the design goals of fields and methods, and also allowing easier, more readable syntax. Well, that concludes my introduction to week 5. Happy reading!
Additional Resources
None...
Good Luck!
[Edited by - JWalsh on August 5, 2007 1:07:56 PM]
