Category Archives: .NET

Using IDisposable with Autofac

Using IDisposable with Autofac presents a few challenges and requires you to really think about lifetime scopes to avoid memory leaks. These days, with pretty excellent garbage collection built into .NET the age-old process of finding memory leaks is usually something that you need not worry about anymore. However, the contract of an IDisposable is something that still requires manual release. And if you’re ever resolving anything deriving from IDisposable using Autofac you’re going to run into problems.

Take a look at this code. What does it do?

using System;
using Autofac;

namespace AutoFacDisposableDemo
{
    public interface IResource : IDisposable 
    {
    }

    public class MyResource : IResource
    {
        private byte[] _lotsOfMemory;

        public MyResource()
        {
            _lotsOfMemory = new byte[1000000];
        }

        public void Dispose()
        {
            _lotsOfMemory = null;
        }
    }

    class Program
    {
        static void Main(string[] args)
        {
            var builder = new ContainerBuilder();
            builder.RegisterType<MyResource>().As<IResource>();
            var container = builder.Build();

            while (true)
            {
                using (container.Resolve<IResource>())
                {
                }
            }
        }
    }
}

At a first glance, it seems to do nothing but feed the garbage collector. But take a look at the memory usage. It will be constantly increasing, and you will run out of memory! If you try removing the IDisposable interface from the IMyResource this code will stop running out of memory. So why does this happen?

Autofac manages your IDisposables

Yes, Autofac tries to be smart and will actually contain a reference to the object internally whenever you resolve a component that is deriving from IDisposable. This is because autofac doesn’t know what other objects might be referencing your resource and you haven’t told it anything on when it is supposed to go out of scope. Especially if autofac is wired in such a way to create non-transient instances where many could be using your disposable object and only the last usage should dispose of it.

This happens transparently, and because you’ve normally done what is usually the right thing and called Dispose on it, you have released the expensive resources on it – leaving only a small skeleton object floating around that never will be garbage collected. This is scary because the memory leak isn’t huge and obvious like forgetting to dispose of sockets that show up pretty quickly. If you run this through a memory profiler it will be held by some internal IDisposable stack somewhere that is rooted to a closure somewhere deep down.

It really is not a solution to try to work around this by removing the from the interface, since that will cause all sorts of problems down the road – breaking the semantics in the processs. Instead what you need to do is to use lifetime scopes. If you change the main loop to this it will run without a leak:

while (true)
{
    using (var scope = container.BeginLifetimeScope())
    {
       var myResource = scope.Resolve<IResource>();
    }
}

Note that we are resolving from the opened scope, and disposing the scope instead of the allocated resources. This is all fine but a bit simplistic. What happens if we are using factory functions instead?

public interface IResourceFactory
{
    IResource GetResource();
}

public class MyResourceFactory : IResourceFactory
{
    private readonly Func<IResource> _newResource;

    public MyResourceFactory(Func<IResource> newResource)
    {
        _newResource = newResource;
    }

    public IResource GetResource()
    {
        return _newResource();
    }
}

class Program
{
    static void Main(string[] args)
    {
        var builder = new ContainerBuilder();
        builder.RegisterType<MyResource>().As<IResource>();
        builder.RegisterType<MyResourceFactory>().As<IResourceFactory>();
        var container = builder.Build();

        var factory = container.Resolve<IResourceFactory>();

        while (true)
        {
            using (var scope = container.BeginLifetimeScope())
            {
                var myResource = factory.GetResource();
            }
        }
    }
}

Out of memory again. Autofac will give you a Func that does new for you in a sense. But that Func is dynamically created to make objects that have the same lifetime scope as the factory object – not the lifetime scope that you called it in! This makes prefect sense in a way, since you can have multiple lifetime scopes going on at the same time – even nested since you can create a lifetime scope from another lifetime scope. Changing it to this will eliminate the problem:

class Program
{
    static void Main(string[] args)
    {
        var builder = new ContainerBuilder();
        builder.RegisterType<MyResource>().As<IResource>();
        builder.RegisterType<MyResourceFactory>().As<IResourceFactory>();
        var container = builder.Build();

        while (true)
        {
            using (var scope = container.BeginLifetimeScope())
            {
                var factory = scope.Resolve<IResourceFactory>();
                var myResource = factory.GetResource();
            }
        }
    }
}

Singletons

Ah, the global variables of the 21st century. What happens if you make the resource factory into a singleton?

var builder = new ContainerBuilder();
builder.RegisterType<MyResource>().As<IResource>();
builder.RegisterType<MyResourceFactory>().As<IResourceFactory>().SingleInstance();
var container = builder.Build();

Bam. Out of memory again! Singletons might be better than globals, but it’s still not a very good idea. The func will be bound to the top lifetime scope and all the IDisposables that gets created are also bound to that scope regardless of how many times you call Dispose on them. A better idea would be to use InstancePerLifetimeScope instead. This removes the problem but also causes the factory to be instantiated several times. Singletons are generally a bad idea, since you can’t be sure who is going to be adding a dependency on an IDisposable and cause memory or resource leak.

More options

There is a Owned class that you can resolve for. So, if you resolve for Owned instead, you are required to release the resource yourself and autofac does no effort to keep the reference in memory any more. Just make sure you call Dispose on the Owned object instead of the internal IResource.

Creating lifetime scopes

You don’t want to pass your scopes around, so you can get the lifetime scope injected for you if you take a dependency on the LifetimeScope object. If you do so, the current lifetime scope from the Resolve will be passed to the constructor from which you can derive more child lifetime scopes or Resolve objects given the current scope. It leaves a bad taste since this has all the trademarks of showing your container since the scope will allow you to create any instance of any type without making an explicit dependency. It would be a better solution to try to avoid this and rely on auto-generated Funcs to create objects in the correct lifetime scope.

In conclusion

  • Be really careful. The leaks are not obvious, and if you’re using other peoples code to inject you can never be sure when they’re using something that is disposable.
  • If you’re using factories, they cannot be singletons if used to create anything IDisposable. In fact, I’d avoid them in general since it’s way too easy to pass a factory from a different scope into a child scope and using that to create objects that will be leaking.
  • Find distinct units-of-work and begin and end lifetime scopes there. This is the place to resolve objects that are all in the same scope.
  • Don’t dispose of injected IDisposables manually. If you work with autofac instead of against it the objects should dispose of them for you. This makes you safe for whenever someone decides to add another usage of your object or change the number of instances created. If you absolutely need to dispose of it manually – make use of the Owned class, and get an object that you yourself are responsible for.
Advertisements
Tagged , , , ,

Why waiting for asynchronous IO is evil

Are you doing IO? If so, who’s waiting on it to complete? IO looks easy on the surface but if you in any way intend to have a fully scaleable application you’ll soon see that this is a delicate and tricky concept. To illustrate this, let’s make a web server real quickly using low level IO!

Old-school IO

using System;
using System.IO;
using System.Linq;
using System.Net;
using System.Net.Sockets;
using System.Text;
using System.Threading;

class Program
{
    static void Main(string[] args)
    {
        var tcpListener = new TcpListener(IPAddress.Any, 1337);
        tcpListener.Start();
        while (true)
        {
            var tcpClient = tcpListener.AcceptTcpClient();
            new Thread(() => HandleRequest(tcpClient)).Start();
        }
    }

    public static void HandleRequest(TcpClient client)
    {
        try
        {
            // Read the entire header chunk
            var stream = client.GetStream();
            var headers = new StringBuilder();
            while (!(headers.Length > 4 && headers.ToString(headers.Length - 4, 4) == "\r\n\r\n"))
            {
                headers.Append(Encoding.ASCII.GetChars(new[] {(byte) stream.ReadByte()}));
            }

            // Find out what was requested in the first line
            // Assume GET xxxx HTTP/1.1         
            var path = new string(headers.ToString().Skip("GET ".Length).TakeWhile(c => !Char.IsWhiteSpace(c)).ToArray());

            // Read the file and serve it back with the minimal headers
            var file = new FileInfo(path);
            var fileStream = file.OpenRead();

            // Minimal headers
            var responseHeaders = Encoding.ASCII.GetBytes(
                string.Format("HTTP 200 OK\r\n" + "Content-Length: {0}\r\n" + "\r\n", file.Length));
            stream.Write(responseHeaders, 0, responseHeaders.Length);
            fileStream.CopyTo(stream);
            fileStream.Close();
        } 
        catch {} 
        finally
        {
            client.Close();
        }
    }
}

Code is easy to read, and straight to follow. But this simplicity is deceptive. You see, what will actually go on here is waiting and locked threads. And locked threads are bad stuff. The read itself will not really run on your thread, instead .NET will be smart and use an IO completion port to get your data from the network if the data isn’t immediately available. This means that you’re wasting a thread. Threads are expensive resources. Not only do they cause context switching but they also each will incur it’s own stack space. This implementation of a web server will never scale because of memory useage.

Waiting is evil

Every time you wait, you are locking up a resource. It’s an important point to make, since the simplicity of the synchronous functions present such a lure to the developer. So we need to make use of the asynchronous pattern, either using the task parallel library or by the Begin/End function pairs. Trouble is that this also presents a way too easy to access waiting handle. If you’re doing an application that needs to scale and that needs to be able to handle lots of IO you can’t do any waiting.

In fact, the task parallel library presents another very nasty gotcha. If you were to wrap code that does waiting inside tasks you are screwing over the task thread pool by occupying tasks in waiting and preventing new tasks from starting. This leads to thread pool starvation and an unresponsive application. When you use the TPL for IO you need to create tasks that encapsulate a singular IO operation in a task using Task.FromAsync in order to make sure that the background IO runs without consuming a thread for waiting.

Thinking asynchronously

The great thing about doing IO async is that if data is not available the function to get it won’t be run by you. You’ll get your stuff back in a callback. This callback runs on the internal worker thread pool. This pool is something you do NOT want to do any sort of long running operations on. It needs to be available to other things.

This has a few other interesting applications. Since you can’t wait for things, iterating becomes really awkward. Consider the loop that reads each byte from the stream to get the header block. You can’t make a loop anymore, since going back and iterating means that the thread that holds control over the loop needs to wait for the result of the operation. So, iterating needs to be accomplished using recursion.

Error handling also becomes difficult. If you throw an exception from inside an AsyncCallback often the application will die straight away. There won’t be a callstack for the exception to propagate back on since the callback has been initiated by the system when the async operation completed asynchronously.

An asynchronous web server

using System;
using System.IO;
using System.Linq;
using System.Net;
using System.Net.Sockets;
using System.Text;
using System.Threading;

class Program
{
    static void Main(string[] args)
    {
        var tcpListener = new TcpListener(IPAddress.Any, 1337);
        tcpListener.Start();
        AcceptClient(tcpListener);

        // To avoid the program exiting
        Thread.Sleep(Timeout.Infinite);
    }

    private static void AcceptClient(TcpListener tcpListener)
    {
        tcpListener.BeginAcceptTcpClient(result =>
        {
            var client = tcpListener.EndAcceptTcpClient(result);
            var stream = client.GetStream();

            // Start next connection attempt
            AcceptClient(tcpListener);

            var buffer = new byte[1];
            var headers = new StringBuilder();

            Action readAction = null;
            readAction = () => stream.BeginRead(buffer, 0, 1, readResult =>
            {
                stream.EndRead(readResult);
                headers.Append(Encoding.ASCII.GetString(buffer));
                if (!(headers.Length > 4 && headers.ToString(headers.Length - 4, 4) == "\r\n\r\n"))
                {
                    readAction();   // Recurse to read one more byte
                }
                else
                {
                    // Assume GET xxxx HTTP/1.1         
                    var path = new string(headers.ToString().Skip("GET ".Length).TakeWhile(c => !Char.IsWhiteSpace(c)).ToArray());

                    // Read the file and serve it back with the minimal headers
                    if (!File.Exists(path))
                    {
                        stream.Close();
                        return;
                    }
                    var file = new FileInfo(path);
                    var fileStream = file.OpenRead();

                    // Minimal headers
                    var responseHeaders = Encoding.ASCII.GetBytes(
                        string.Format("HTTP 200 OK\r\n" + "Content-Length: {0}\r\n" + "\r\n", file.Length));
                    stream.BeginWrite(responseHeaders, 0, responseHeaders.Length, writeResult =>
                    {
                        stream.EndWrite(writeResult);
                        byte[] fileBuffer = new byte[file.Length];
                        fileStream.BeginRead(fileBuffer, 0, (int)file.Length, fileReadResult =>
                        {
                            fileStream.EndRead(fileReadResult);

                            stream.BeginWrite(fileBuffer, 0, fileBuffer.Length, contentWriteResult =>
                            {
                                stream.EndWrite(contentWriteResult);
                                fileStream.Close();
                                stream.Close();
                            }, stream);
                        }, fileStream);
                    }, stream);
                }
            }, stream);
            readAction();

        }, tcpListener);
    }
}

The code above is obviously for demonstrative purposes. Generally it’s not a good idea to read single bytes from streams, and in this case it’s an especially bad idea since it generates an impressive call stack from the recursion. But it shows the general idea on how you should code to achieve an IO-bound application that will scale. There are no explicit threading. No thread is ever in a waiting state. The application becomes entirely reactive to IO instead of reading and waiting for IO to complete. Interesting things happen when you start to run this and break and a random point. All threads in the worker thread pool are normally doing nothing, which is great because this means that they’re available to the system to quickly process IO callbacks. A request to this server will not spin up a thread. The memory usage will be kept absolutely minimal.

The situation improves somewhat with the new .NET 4.5 which has the async/await keywords built in. Improves in the way that the syntax becomes nicer but the lessons still hold true. If you’re waiting on anything you’re killing your application with wait handles and no amount of async keywords are going to rescue you. It’s a pity that most of the examples of doing asynchronous operations in the documentation often show off ways to use WaitOne that pretty much totally defeats the purpose of being asynchronous in the first place.

Tagged ,

Fun with Moq: Dynamic mocking

Run time mocking

Sometimes it’s useful to be able to create a Mock object without the type being known at compile time. Normally when using Moq you create a Mock object using this syntax:

var mock = new Mock<IMyInterface>().Object;

But what if IMyInterface is not known at compile time? What you would like would be to do this var mock = new Mock(myType).Object and receive the mocked object back. Turns out this method does not exists, but it’s possible to get around this using the magic of reflection!

public static object DynamicMock(Type type)
{
   var mock = typeof(Mock<>).MakeGenericType(type).GetConstructor(Type.EmptyTypes).Invoke(new object[] { });
   return mock.GetType().GetProperties().Single(f => f.Name == "Object" && f.PropertyType == type).GetValue(mock, new object[] {});
}

This piece of code will return to you a mock that implements the interface type you specify and return it as an object. This could then be used for various fun stuff to automate the unit testing of certain things.

Dynamic parameter checking

Seen this code before?

public class MyConcreteClass 
{
   private readonly IDependency1 _a;
   private readonly IDependency2 _b;
   private readonly IDependency1 _c;
   private readonly IDependency1 _d

   public MyConcreteClass(IDependency1 a, IDependency2 b, IDependency1 c, IDependency1 d)
   {
     if (a == null) throw new ArgumentNullException("a");
     if (b == null) throw new ArgumentNullException("b");
     if (c == null) throw new ArgumentNullException("c");
     if (d == null) throw new ArgumentNullException("d");

     _a = a;
     _b = b;
     _c = c;
     _d = d;
   }
}

It’s great to cast all those ArgumentNullExceptions to check the value, but testing this is a complete pain, since you’d need four separate test cases for each parameter to verify that the correct exception is being thrown. With dynamic mocking and some reflection this can be totally automated for classes that only take interfaces as parameters – which in a heavily dependency injected application is pretty much all of them.

All you need to test this scenario is a single call to NullParameterCheck<MyConcreteClass>() and this method somewhere in your testing code.

public static void NullParameterCheck<T>()
{
	var constructor = typeof(T).GetConstructors().Single();

	Assert.IsFalse(constructor.GetParameters().Any(f => !f.ParameterType.IsInterface), "All parameters must be interfaces in order to use this helper");

	for (int i = 0; i< constructor.GetParameters().Length; ++i)
	{
		var paramName = constructor.GetParameters()[i].Name;
		int i1 = i;
		var args = constructor.GetParameters().Select((p, ix) => ix == i1
			? null
			: DynamicMock(p.ParameterType));
		try
		{
			constructor.Invoke(args.ToArray());
			Assert.Fail("No exception for parameter null {0}", paramName);
		}
		catch (TargetInvocationException e)
		{
			Assert.IsTrue(e.InnerException is ArgumentNullException);
			Assert.AreEqual(paramName, ((ArgumentNullException)e.InnerException).ParamName);
		}
	}
}

This code will loop around each parameter, replacing one of them with null in turn to verify that each interface parameter will generate the corresponding ArgumentNullException

Happy mocking!

Tagged , , , ,

The language feature abuse threshold

C# has an odd strategy to language features which can probably be best approximated with “That looks cool, let’s put it in”. This has resulted in a language which is about as full of syntactic sugar as the very best of them.

As an example, C# now has lambdas since a few years back. They’ve got their own syntax as well. Not that we actually needed lambdas in a strict sense, since we got delegates before that. Not that we needed those either, since we’ve got objects and interfaces to pass around. Which weren’t themselves needed. The only thing you really need is a few machine code instructions. Or, given a convoluted example you need only one assembly language instruction.

Of course you don’t want to code in that, so you’d end up writing in some type of sugar coated language in order to be as productive as possible. But, when are you crossing the threshold of overusing language features just because you can?

My example here is, again, going to be the lambda functions in C#. In part because I am using those myself a lot, and the usage is increasing – maybe in part due to my experience with Haskell which really turned me on to using a functional style.

Local functions

Lambdas let you make local functions, something which isn’t possible using a normal member function. Which means you can create something like this.

public void DoStuff(string message)
{
    Func<string, bool> messageContains = s => (message??"").Contains(s);
    if (messageContains("this"))
    {
        //.. stuff
    }
    else if (messageContains("that"))
    {
        // .. other stuff
    }
}

This saves quite a few characters to type, since you’d get a useful null safe comparison but it’s only scoped in the local function and doesn’t pollute your class. Overuse, or clever?

Self recursive lambdas

This Fibonacci function works just like the standard double recursive function, but from within a local scope.

Func<int, int> fib = null;
fib = f => f < 2 ? f : fib(f - 1) + fib(f - 2);

Granted, this is contrived and probably in all sorts of bad styles? Or appropriate somewhere?

Functions returning functions

My favourite, honestly very very useful, but would you yourself use this? Overuse?

public bool HasSpecificChildren(XDocument doc)
{
    Func<string, Func<XContainer, bool>> hasDescendant = 
        name => e => e.Descendants(name).Any();
    Func<Func<XContainer, bool>, Func<XContainer, bool>, Func<XContainer, bool>> and =
        (a, b) => x => a(x) && b(x);

    return and(hasDescendant("child"), hasDescendant("otherChild"))(doc);
}

In case it’s not obvious, this code is equivalent to this

public bool HasSpecificChildren2(XDocument doc)
{
    return doc.Descendants("child").Any() && doc.Descendants("otherChild").Any();
}

Now, interestingly, though this example is a bit over the top – which of the two implementations is the most redundant. I’d say it is the second one. The lambda sillyness only repeats the functionality once for each part and is actually as factored as you can get. Consider if you were to change the implementation from Descendants to Elements. One solution has only one place to change..

Currying

A final piece of something that probably is a bit from the Haskell world, though interestingly enough the venerable Jon Skeet wrote about it.

Currying is the idea that each function only really needs one argument. This can be achieved in C# as well. Consider this.

public static Func<T1, Func<T2, Func<T3, TResult>>> Curry<T1, T2, T3, TResult>(Func<T1, T2, T3, TResult> uncurried)
{
    return a => b => c => uncurried(a, b, c);
}

static void Main(string[] args)
{
    Func<string, string, string, string> func = (a,b,c) => a + b + c;
    var uncurried = func("currying", "is", "awesome");

    Func<string, Func<string, Func<string, string>>> curry = Curry(func);
    var curried = curry("currying")("is")("awesome");
}

This is very rarely seen in C#, but is a mainstay of other languages and can prove very useful indeed for function composition. So, are we abusing the language enough? Or do we need to go even further.

All of the things above have their place in your development toolbox, honestly. But when are you overusing them?

Is it OK to make a local lambda statement in order to avoid passing an argument to a private function? I know I make local lambdas constantly for this very reason. Is it cool to prefer LINQ to avoid making for loops? Should you avoid the var keyword because someone else might get confused of your typing intentions or just go along with the speed of development that it offers constantly?

When are you over the line? And who is to determine what is acceptable?

Hosting a WPF control inside a MFC window and making the keyboard work

It’s quite possible to host a brand new shiny WPF control inside your smelly old MFC or even Win32 windows. It’s not particularly hard to do so, but you will need to do a few obscure things to make this work. Also, the intellisense that VS provides isn’t operational when working with C++/CLI. So you’ll pretty much have to know what you’re doing.

Similar code such as this can be found, but they often gloss over the details, such as how to deal with feeding the keyboard events to the child window, and how to make sure that the child window will receive tab events. I’ve included this as well, since you’ll probably want those things when integrating your new component.

First off, in your MFC project you’ll need to turn on support for common language runtime (the /clr flag) and you need to set the CLR-tread attribute to STA-thread in the project which ultimately hosts your .exe file. If you don’t do the STA-thread it will crash horribly and it will not be obvious why it has done so. In fact, the only hint is that it seems to crash even before it has a chance to be able to do so. That’s because the default setting is to handle the windows with multiple threads, something which WPF chokes on. The setting is found under Linker->Advanced.

For the sake of discussion lets say you have a dialog which extends the MFC class CDialog. You want to replace the contents of the window with a WPF control. First there is a few things that needs to be added, namely two references that needs to be kept in the dialog to keep the garbage collector from raining on our parade. In the header add two gcroot members:

gcroot m_hwndSource;
gcroot m_wpfControl;

Now to the more interesting bits, how to actually create an area for the WPF control to live in. What you actually need to do is to create something called a HwndSource. This object is a ‘real’ windows window and as such can receive windows messages and are actually understood by the windows system. A fundamental difference between WPF and Winforms/MFC/Win32 is that WPF does not have a HWND for every component that you create. It will only have one outer window and nothing more. This outer window is not created by itself, instead we need to provide such a window for WPF to live in. In some suitable place like the handler for WM_CREATE in your CDialog add this.

System::Windows::Interop::HwndSourceParameters^ sourceParams = gcnew System::Windows::Interop::HwndSourceParameters("MyWpfSourceWnd");
// This sets the position within the parent window
sourceParams->PositionX = 0;
sourceParams->PositionY = 0;
sourceParams->ParentWindow = System::IntPtr(this->GetSafeHwnd());
sourceParams->WindowStyle = WS_VISIBLE | WS_CHILD;

System::Windows::Interop::HwndSource^ source = gcnew System::Windows::Interop::HwndSource(*sourceParams);
MyWpfControl^ wpfControl = gcnew MyWpfControl();

// This creates sets the root visual of the interop component to out user control.
// As a sidenote, THIS is where it crashes if you have forgotten to set STA-thread.
source->RootVisual = wpfControl;

// Adds a keyboard hook!
source->AddHook(gcnew System::Windows::Interop::HwndSourceHook(ChildHwndSourceHook));

// This is the HWND of the interop component, should you choose to save it.
m_wpfChild = (HWND)source->Handle.ToPointer();
   
// This is important! If you do not save these the garbage collector eats them up!!
m_hwndSource = source;
m_wpfControl = wpfControl;

You might have noticed that we also added a hook to the window. This is needed, since if we do not do this your WPF control is never going to receive any keyboard events. The mouse however still works. This is a simple function outlined below:

System::IntPtr ChildHwndSourceHook(
    System::IntPtr /*hwnd*/, int msg,
    System::IntPtr /*wParam*/, System::IntPtr /*lParam*/, bool% handled)
{
    if (msg == WM_GETDLGCODE)
    {
        handled = true;
        // WANTCHARS = input boxes work
        // WANTTAB = tab order works
        // WANTALLKEYS = Enter key will work
        return System::IntPtr(DLGC_WANTCHARS | DLGC_WANTTAB |DLGC_WANTALLKEYS);
    }
    return System::IntPtr(0);
}

This is pretty much all you need to do. Note that there is nothing strange at ALL with the WPF usercontrol. No modifications needed, which also means that you can insert ANY of the cool WPF controls into your MFC application. Also, should you be stuck in Win32 country this works just as well, you just need to provide the parent HWND in another way than this->GetSafeHwnd().

Now go out and create your frankensteinian interop apps to terrorize the neighborhood.

Tagged , , ,

How to handle WPF events in native MFC code

I’ve recently had the dubious pleasure of getting to know C++/CLI and revisiting my good old buddy MFC. The task at hand was to integrate a WPF component into an existing MFC application. That task in itself is probably interesting enough to warrant it’s own post but suffice to say that I got this working properly. This means that we’ll end up with a class deriving CDialog that holds a WPF component inside it. Now we want to handle events. In WPF country, this is easy: add this to our WPF class:

public event EventHandler OnMyEvent;

And in our dialog we hold the WPF control in a gcroot<MyWPFControlClassName>. We also have a method we’d like to get called.

void MyDialogClass::OnEvent(System::Object ^sender, System::EventArgs ^args)
{
   // Do stuff
}

First off, what prompted this article is what does not work. You cannot from your unmanaged dialog class pass a pointer to your member function to your event like this.

wpfControl->OnMyEvent += gcnew System::EventHandler(
      this, 
      &MyNativeDialogClass::OnEvent);

This does not work, and it’s because your class is not a managed class since it’s not declared as ref class. The error message is also less than helpful. So how to solve this? You need a wrapper. Create this class somewhere in your project.

#pragma once

template<class T> ref class ManagedEventWrapper {
public:
   typedef void(T::*MemberFunction)(System::Object^ sender, System::EventArgs^ args);

   ManagedEventWrapper(T& host, MemberFunction function)
      : m_host (host)
      , m_function(function) 
   {
   }
   
   void OnEvent(System::Object ^sender, System::EventArgs ^args)
   {
      (m_host.*m_function)(sender, args);
   }

private:
   T& m_host;
   MemberFunction m_function;
};

If you then include this file in your MFC class, then you can subscribe to events like this:

wpfControl->OnMyEvent += gcnew System::EventHandler(
      gcnew ManagedEventWrapper<MyNativeDialogClass>(*this, &MyNativeDialogClass::OnEvent), 
      &ManagedEventWrapper<MyNativeDialogClass>::OnEvent);

This creates the neccessary layer of extra indirection around the native code to make the event handling work properly. You don’t need to save the reference to ManagedEventWraper since the reference is held by the System::EventHandler which makes sure it does not get garbage collected.

Tagged , , , ,

Exception handling done the right way

I love exceptions, but I get a distinct feeling many people don’t when I see some horrific examples of their use. Especially from people who gets forced into using them by javas wonderful checked exception feature without truly understanding the concept. Or by people so scared of them that they hardly dare catch it, like way too many of the C++ crowd. In these enlightened days, exceptions don’t cause the problems they used to cause, unless you are working with old C++ code which doesn’t use auto_ptr. If you are, abandon all hope and refactor hard.

I’m going to assume you’re writing C# here, but everything I say goes for Java as well. It’s even better there since Java has checked exceptions. But without further ado here’s my handy-dandy guide how to do it right!

Why bother

Because it’s a graceful way of handling exceptional circumstances. Anything that is not considered a normal result of your method that might happen is an exceptional circumstance. Return values are not for exceptional circumstances. I assume you like the .NET framework or Javas similar environment. They’re nice because of exceptions! To see the alternative, take a look at for instance straight up COM in C++. It’s clunky as hell. Without exceptions, the only way to check for any errors is to check return values. Whenever you do something you’ll invariably get the real return value as a pointer-to-a-pointer and the method itself returns a HRESULT which you need to check. But of course, you won’t, since they almost never fail and you will forget. And you can’t read the code like it’s supposed to be read since the return values will be in the parameter list instead of in the actual return.

To compound the problem further C# has an out and a ref specification to parameters. Which is almost in all cases used for this sort of stuff, and almost always totally evil in my book for the reasons stated above. You should never ever do this sort of stuff:

string DoStuff(out BusinessObject bo) {
    // Doing stuff
    // ...
    // Business plan bad, return error
    return ".COM boom failed";
}

The only way to find out what went wrong it to do string compared on the return value. Evil. Return value checking should be a thing of the past for non-exceptional circumstances.

How do I do it then?

Lets start by how to not do it. Here’s a typical example of doing it wrong

void DoStuff() 
{
	// stuff goes wrong
	throw new Exception("Shit is hitting fans");
}

NO! You don’t throw the Exception class, never ever. I wish they made it abstract. This circumvents the catch statements intended use, makes it impossible to tell what’s going wrong and makes babies cry. If you specify an Exception type to catch it will catch every exception. Whatever it was you’ll have to figure out yourself. It might have been shit hitting fans, but it might as well have been a null reference. Maybe it was a division by zero. Who knows?

If shit is hitting fans, you throw a very specific exception relating preferably to that case and no other case.

public class ShitHitFanException : Exception 
{
    public ShitHitFanException(string message) : base(message 
}

void DoStuff() 
{
	// Danger Will Robinson!
	throw new ShitHitFanException("Scotty can’t change laws of physics");
}

And you catch it by catching the exception you need to handle, permitting the stuff you’re incapable of handling to bubble up to the surface. Maybe even to a crash, if that’s your cup of tea.

try
{ 
    DoStuff();
}
catch (ShitHitFanException e) 
{
    // Alert Will Robinson of danger.
}

This leads to my next point. You need to use base classes for your exceptions if they have any sort of common ground. Just routinely declaring exceptions as being subclasses to Exception like a big happy community of equals is evil. You need to categorize your exceptions into types of exceptions. For instance, if you have some sort of method which handles files, you might be throwing FileNotFoundException, DirectoryAccessDeniedException and DiskFullException. These have common ground, and should be labeled as such by inheritance. You need a IOException base class. This makes your catching code able to intelligently decide if it wants to handle exceptions specifically or more sweeping without resorting to acts of evil like catching Exception.

More importantly it also enables you to do cool stuff like

void ShuffleImportantDocumentsFromTopDrawer(Document[] topDrawer) 
{
    try
    {
        foreach (var document in topDrawer) 
        {
            try
            {
                document.shuffle();
            }
            catch (FileNotFoundException e) 
            {
                // Dog probably ate it. Log a warning and continue
            }
        }
    }
    catch (IOException e) 
    {
        // We end up here for BOTH DiskFullException and 
        // DirectoryAccessDeniedException
        CallTheItGuy();
    }
}

This is impossible to do gracefully if you have screwed up your inheritance chain or are catching Exception itself. Exceptions have no relation to another, and you can’t catch two similar exceptions handling them the same way without resorting to copy and paste or putting the handling in a separate method, which is weird and ugly. This is oftentimes a problem wih Java file IO. They throw exceptions like there’s no tomorrow and you’re required to catch them all. You probably want to handle some of them the same way. Catch the base class and you’re set.

But, I don’t want to handle it you say. I want someone else to do it for me. First of the bat, lets never ever do this again:

try 
{
    FaultyMethod();
}
catch (FaultyException e)
{
   // Whoops. I cant handle this stuff. Do some clean up and signal errors again
   throw new OtherException("There was a problem with faulty method, big surprise");
}

NO. There’s one huge glaring problem here. You are marshalling away the cause of the exception! The hard and fast rule is: If you are throwing something from inside a catch, you need to supply the exception you throw with it’s underlying cause. Here is the corrected code:

   throw new OtherException("There was a problem with faulty method, big surprise", e);

See how we added the e to the constructor. This makes a world of difference! When you print a stack trace, you’ll be pointed to the correct line, instead of being pointed to the catch block which says absolutely squat about the real nature of the problem.

Another point I’d like to make is that you shouldn’t throw another exception unless you have changed the meaning. But you can still catch stuff and log. As an example, say you have a SOAP service. Since you are diligently applying the principles in this article, you’re using exceptions to handle SOAP errors (they serialize fine, don’t worry about it). But you want a log on the server side as well of any exceptions sent to the client. Enter the second (under)used use of the throw keyword – the parameterless throw.

string MySoapyMethod(string param) 
{
    try 
    {
        // Do cool stuff that fails...
        BrokenCode();
    }
    catch (BrokenException e)
    {
        // Log this stuff so that we know about it
        Log.Error("Broken stuff in Soapy method", e);
        throw;
    }
}

This will throw the exception without altering it in any way. This is the other legal way of handling stuff you don’t want to or can’t handle. A final point, when you log using your logging framework, such as log4net, you typically get an option to pass an exception. Use it. If you have an exception logging, never log Log.Error(e.Message). Always log Log.Error("A real description of what went wrong", e). That way, you’ll still preserve the precious stacktrace.

Tagged , ,

MVC Validations 4: Whole class business object attribute validations

Sometimes you need to validate an object where the column data itself isn’t enough to determine if the object is valid from a business perspective. However, this doesn’t mean you have to abandon attributes for validation!

As an example say we have this class:

public class BusinessObject
{
    public int PropA { get; set; }
    public int PropB { get; set; }
    public int PropC { get; set; }
}

Our BusinessObject class here, say it’s only valid if the three properties have a sum of 100. Obviously we can’t set max and min values on the properties themselves to achieve this. What we need is an annotation attachable to the class itself. It works like this:

[AttributeUsage(AttributeTargets.Class)]
    public class NumberSumAttribute : ValidationAttribute
    {
        public override bool IsValid(object value)
        {
            var businessObject = value as BusinessObject;
            if (businessObject == null)
            {
                throw new ArgumentException("This annotation is not attachable to this object class");
            }
            return businessObject.PropA + businessObject.PropB + businessObject.PropC == 100;
        }
    }

Attach it to the head of your class like this

[NumberSumAttribute(ErrorMessage = "All fields must add up to 100.")]
public class BusinessObject
{
    public int PropA { get; set; }
    public int PropB { get; set; }
    public int PropC { get; set; }
}

That’s pretty much it. An obvious sticking point here is the class cast, but as far as I know I cannot restrict the validation attribute to only being applyable to some types. It’s possible to achieve this in some fashion by fidding around with access restrictions and inheritance like this if you really think you need this compile time security.

Oh, and since you won’t get the validation message on a field anymore you’ll need to stick the class generic validation messages somewhere. Add @Html.ValidationSummary(true) where you want these messages to appear, and you’re good to go!

Tagged , ,

Things I would like C# to have

In general C# is a great language, but being a long-time polyglot there are two things I’m really missing which I think would make the language better.

Checked exceptions

I come from a long stint in Java, which has these, and I really don’t understand the reasons for not including them in C#. As far as I know this is the answer straight from the horses’ mouth. For those that don’t know what checked exceptions are; they are exceptions that you have to either catch or throw to the next guy. Like this in java:

void foo(int x) throws SomeException()
{
   if (x == 42) throw new SomeException();
}

Any code using foo have to either catch it or declare that they also throw it. This causes an automatic documentation of what serious errors can happen in a function, since you are required to handle it. When I program in C# I just don’t know what bad things can happen in my code without looking at some other documentation than what intelliSense + resharper gives me. I find this scary, and I constantly wonder if I’m having holes in my application.

For this reason, I would really like to have this in C# in some shape or form. I don’t buy the reason of version compatibility or that people are sloppy and just go re-throwing everything. If you have that problem, your developers are at fault and you can’t design a language based on that.

Const the way it should be

Have you ever done C++? Have you ever done the const keyword the way it’s supposed to be used?

Const in C++ isn’t just a replacement for an evil #define. Oh no, it’s a whole new world once you understand it. Here’s a valid class signature in C++:

class Foo
{
    const Foo const * bar(const Foo const * foo) const;
}

In understandable terms, this it what the signature says: A method named bar takes a pointer whose location may not change and that may not be used to change whatever it points to returns a similar unchangeable pointer while not altering the class in any way.

Wow.

The final const on the method is the really interesting one. It says that calling this method on the class will not change the class at all. So if you have a const instance of the class, you can all all the methods that guarantee that the class won’t change – but you can never call the non-consted ones.

Also the const* is interesting. Const in C# means I cant change what the reference points to. That is what the const before the class name stands for in C++. But the const* means I cant change the actual object at the end of my pointer.

Another awesome thing is that you can overload methods by just varying their const-ness.

Had I had this in C# I could writer safer code with less change of side effects. Also it would not really impact existing code that much. I don’t get why C# doesn’t have it. Perhaps a constref keyword to not break existing stuff? I get the feeling the real reason for not doing this is because most people doing C++ don’t understand how awesome const is. Whenever I do C++ I feel it’s almost my sacred duty to promote it’s proper use.

How about you, is there anything you miss? Please do leave a comment, I’d love to hear from you!

Tagged , ,

MVC Validation 3: Unobtrusive validation in Ajax-loaded partial views

It’s a pretty good idea usually to not reload the entire page, but if you use MVCs now-standard unobtrusive validation you’ll find that the validation does not work on the partial you’ve just loaded.

Here’s how you solve this. Say you have a page which uses a script to load a view using ajax to a div, something like this:

function loadStuff()
{
    $('#myDiv').load(window.location.pathname + "/Stuff");
}

If you do this and don’t do anything else, the unobtrusive validation won’t work at all. If you try to brute force your way of of this by including the unobtrusive validation javascripts again on the partial view, the validation will kinda-sorta-work. But really, it doesn’t work. Instead what really want to do is to reparse and rebind the validation. Including this at the bottom of the partial view you want to load will work.

<script type="text/javascript">
    $(document).ready(function () {
        $.validator.unobtrusive.parse("#myDiv");
    });
</script>

I’m not sure if it would be a better fit to place this in the ajax-loader method instead. I think I had some problems with that and went with putting this in the bottom of the page. You can reparse the entire document if you want to no real ill effect, but parsing the div you just loaded is probably more efficient.

There’s nothing more to it really, but it’s a real gotcha that at had me confused at first.

Tagged , , ,