Deep Dive on Closure Pitfalls

I’ve blogged about closures in C# and their pitfalls before.  I keep seeing problems with closures–more now that lambdas expressions and statements (“lambdas”) are becoming more widespread–even with experienced developers. So, I’d thought i’d post about some of the details surrounding where the C# compiler generates closures in the hopes that people will recognize more where they write code that creates a closure and its context. The C# language spec does not refer specifically to “closures”, with regard to capturing state for anonymous methods (including lambdas)–it refers to “outer variables” and “captured outer variables”.  The captured outer variables for a specific … Continue reading Deep Dive on Closure Pitfalls

DevTeach 2009 Vancouver

The schedule for DevTeach 2009 Vancouver has been announced (  There’s lots of great software development sessions from some of the leaders in our industry. If you’re planning on improving yourself, this is the conference to go to.  Not only can you attend excellent sessions; but you can hob-knob with the presenters and pick their brains. If you have a friend or co-worker who’s interested, there’s a limited-time two-for-one offer for an even better price:

ITSWITCH #1: Answer

Last post I detailed some code that may or may not have something wrong in it.  If you thought InitializeOne and IntializeTwo are semantically identical (e.g. they differ only by performance), you’d be wrong. If you simply ran the code, you’d be able to guess where the problem is.  To understand what’s causing the problem.  Let’s look at how C# effectively implements the two loops. InitializeOne is essentially equivalent to         private class PrivateDelegateHelper         {             public String Value { get; set; }             public void Method()             {                 TestClass.ProcessText(Value);             }         }           public void … Continue reading ITSWITCH #1: Answer


Is There Something Wrong In This Code Here UPDATE: as several readers pointed out there was compile error in the code what was being displayed.  The line “String value = string[i]” was showing up as “String value = string”.  I’m not sure why; but throwing some spaces between the i and the square brackets seems to have solved it. In the following class, is there something wrong with either InitializeOne or InitializeTwo (hint, it has nothing to do with compile errors and I’m ignoring performance differences)?     public class TestClass     {         private List<MethodInvoker> delegates;           private … Continue reading ITSWITCH: #1

.NET 2.0 Framework License

End-User License Agreement MICROSOFT SOFTWARE SUPPLEMENTAL LICENSE TERMS MICROSOFT .NET FRAMEWORK 2.0 Microsoft Corporation (or based on where you live, one of its affiliates) licenses this supplement to you. If you are licensed to use Microsoft Windows operating system software (the “software”), you may use this supplement. You may not use it if you do not have a license for the software. You may use a copy of this supplement with each validly licensed copy of the software. The following license terms describe additional use terms for this supplement. These terms and the license terms for the software apply to … Continue reading .NET 2.0 Framework License

Formatting/parsing for a specific culture redux

In recent blog post I detailed how creating a culture via the CultureInfo constructor could actually create a user-overridden culture–which could be completely different than the culture that you’ve requested by name.  Fortunately there’s a way of overriding the user override (apologies for overloading “override”) by supplying the boolean value “false” in a CultureInfo overload. As Greg Beech commented, there’s another method to create a culture–System.Globalization.CultureInfo.CreateSpecificCulture.  This sounds like it does exactly what you might expect and creates a “specific” culture.  Unfortunately, this method too violates the principle of least astonishment and creates a culture that uses the user-overridden values when the culture … Continue reading Formatting/parsing for a specific culture redux

Using Exceptions For Normal Logic Flow

The generally accepted wisdom is that you shouldn’t use Exceptions for normal logic flow.  Normal logic flow is a bit subjective; but anything that must happen at least once in all known scenarios is normal logic flow. Enter XML Serialization in the framework.  The framework actually dynamically creates types that perform the actual serialization of a given type and caches that assembly.  The next time that type needs to be serialized it reuses that generated type, reflection is minimized and things happen pretty quickly. Here’s the rub.  The framework decides that it must generate the type when Assembly.Load generates an … Continue reading Using Exceptions For Normal Logic Flow

Who’s Referencing Whom?

When developing any sort of application, debugging in inevitable.  Sometimes, part of that debugging means trying to figure out why objects haven’t been collected and therefore figuring out what object is referencing the object that has yet to be collected. There’s many reasons why you’d want to find out what object is referencing, like suspected memory “leaks”. With Visual Studio (and MDbg) you can use a tool called SOS (or Son Of Strike).  This is included in the .NET installation.  To use SOS you first need to enable unmanaged debugging in your project (Project\Properties, Debug tab, check “Enable unmanaged code debugging” in … Continue reading Who’s Referencing Whom?

Thread.Abort is a Sign of a Poorly Designed Program

Continuing the theme of Thead.Sleep is a sign of a poorly designed program, I’ve been meaning to provide similar detail on Thread.Abort and not just allude to it in other posts like ‘System.Threading.Thread.Suspend() is obsolete: ‘Thread.Suspend has been deprecated…. Many of the concepts I’ve discussed regarding Thread.Suspend also apply to Thread.Abort, and in much the same way that the ability to terminate a thread has existed for so long that the concept has remained ubiquitous when dealing with threads and it just keeps getting implemented without thought.  Thread.Abort is far more unsafe than Thread.Suspend; but, unfortunately Thread.Abort has yet to … Continue reading Thread.Abort is a Sign of a Poorly Designed Program

Performance Implications of try/catch/finally, Part Two

In a previous blog entry Performance Implications of try/catch/finally I outlined that the conventional wisdom that there are no performance implications to try blocks unless an exception is thrown is false.  I have some clarifications and details to add. My original tests used academic sample code like this:         public int Method( )         {             int i = 10;             try             {                 i = 20;                 i = 30;                 Thread.Sleep(i);             }             finally             {     … Continue reading Performance Implications of try/catch/finally, Part Two