In your experience, what do you see (or hear) as common misunderstandings about how things work in .Net?
I'm not thinking of common programming mistakes, such as
throw ex
to rethrow an exception, but rather common misconceptions about how the framework works such as:
the [Serializable]
attribute is required for xml serialization, or that the default object.GetHashCode()
implementation somehow considers all private fields in your type.
One of the reasons I am asking this question is that I spend a lot of my professional time mentoring junior developers and I feel it is important to understand where the common misconceptions are. As someone who has used .Net for a long time I am guessing that there is a lot of knowledge I consider to be obvious, but actually may not be. I personally can't remember when I learnt the many nuances of how things work (and, of course, I'm sure I still have many left to learn!).
IDisposable and the way the garbage collector works. A common misunderstanding surrounds the purpose of IDisposable.
I often see people not understanding that calling Dispose() on an object does not release memory, and IDisposable does not (directly) have anything to do with memory usage.
using(obj) { }
will "clean up" obj at the end. - Rex M
Not understanding that everything is by default passed by value, even references. A copy of a reference is passed, not the original reference, unless of course you are using the 'ref' keyword:
class Foo
{
public string Name;
public Foo( string name ) { Name = name; }
}
void Main( )
{
Foo f = new Foo( "Original" );
ChangeRef( f );
Console.WriteLine( f.Name ); // prints "Original";
ChangeName( f );
Console.WriteLine( f.Name ); // prints "Modified";
}
static void ChangeRef( Foo f )
{
f = new Foo( "Modified" );
}
static void ChangeName( Foo f )
{
f.Name = "Modified";
}
One for asp.net - using an empty shell .aspx page for the codebehind where an HttpHandler would be appropriate. Not nearly enough people know about HttpHandlers.
The (exact) meaning of reference-type vs value-type.
All too often the "Value types are allocated on the stack" description turns up.
To add my own description:
The main difference lays in the copy-semantics, not in the memory allocation. Stack/Heap do play a role in understanding it all though.
Value Types are allocated inline, as local variables (stack) or as fields/elements inside reference types (heap).
Instances of Reference types do not have a name, they can only be instantiated on the heap and are always accessed through references.
References are (behave exactly as) value types.
Some of the confusion may come from the double role the references play:
int n = str.Length; // A
str = null; // B
in A, str is indistinguishable from the object-instance, in B str is clearly just the reference.
More focused on ASP.NET specifically, is that Webforms has left many developers with the impression HTML only allows one FORM element per page.
String immutability, the symptom being usage of the '+' string concatenation operator.
The page lifecycle, especially with the use of master pages.
The key is how 4,5 and 6,7 are not what you'd expect!
Not knowing that Response.Redirect throws an exception when calling it.
try {
if (1>0)
Response.Redirect("somepage.aspx");
}
catch {
//Response.Redirect throws an exception
//to stop the current thread.
}
That an operation on a string modifies that instance.
string s = "Bob & Lis";
s.Replace ("Lis", "Jenny"); // Won't modify the string but return a modifed copy
s = s.Replace ("Lis", "Jenny"); // Now we have it
A very basic thing: the distinction between an object and the reference(s) to that object.
Not understanding the nuances when passing between gc managed objects and explicitly managed objects or when this state flips. In Winforms, a control is memory managed until its handle gets created, then is explicitly managed until OnHandleDestroyed at which point it is gc managed again.
Yes, it has a .Dispose() method. No, you are not guaranteed it gets called. No, you are not guaranteed that its constructor will be balanced with an OnHandleDestroyed call. Set up explicitly managed objects and subscribe to events in OnHandleCreated(), drop them in OnHandleDestroyed(), any other thinking -> MEMORY LEAK or worse.
The biggest one I've come across is when doing web forms in asp.net. A developer will create a class member variable and set it on page load, but then when they are doing processing in a button click event they scratch their head as to why that variable is now null. They don't understand that http is stateless that they have to explicitly keep the state of their variables some place(viewstate, querystring, etc.)
The false idea that Visual Basic .NET and C# are completely different technologies, while actually both are languages based on the .NET framework and at the end it does not matter which one you use.
Perhaps not very common but I once came across this little beauty
public Image LoadImage(String imageFile)
{
try
{
return Image.Load(imageFile);
}
catch (OutOfMemoryException)
{
GC.Collect();
return Image.Load(imageFile);
}
}
What the author didn't realize is that the CLR automatically invokes a full collection before throwing the exception. When .NET says you're out of memory - you really really are.
PS. This was a WINCE app so memory usage was an issue.
Something that I see, is that there doesn't seem to be an understanding of the stack and the heap that is essential to how memory works in an application. The idea of a Value Type and a Reference Type seem to be known, but the difference, in terms of how the stack and the heap come into play is not understood.
I think this is due to the lack of pointers and garbage collection. Still, I think it's a core concept to anyone programming any OO language.
Using Linq to modify data, rather than just Querying.
Deferred execution.
Assigning object to null, makes it eligible for Garbage Collection.
Many people feels as though they can type .whatever and make anything happen. But to quite the contrary you actually have to know the inner workings of classes, properties, design, platform, etc....to actually utilize it's full purpose.