Being Cellfish : .Net

How do I get someWin32API method to work in .Net?

cellfish — Sun, 01 Nov 2009 21:11:00 GMT

It was some time since I last needed to use P/Invoke but it seems like I always need something from a standard C DLL or the Win32 API. Not that I needed it today, but I stumbled across this site which I will remember for future reference. Looks very helpful.

Exceptions or not?

cellfish — Fri, 02 Oct 2009 08:01:00 GMT

I've always had mixed feelings for exceptions. First of all exceptions should only be used for exceptional things, not things that are expected. For example if you open a file it may fail for several reasons; it does not exists, you do not have rights to open it or it may be locked. These are all perfectly reasonable errors and throwing an exception for these failures is in my opinion not a great API design. If there are other methods to check for all these circumstances it might be OK but not optimal. A reasonable compromise is to have a TryOpen method which never throws an exception. This gives the user of the API the option of letting file open errors being expected or fatal.

Because exceptions should only be thrown for exceptional circumstances there should be no reason to catch them other in the application's main loop unless you can add information to the error in which case you want to wrap and throw a better exception. The exception to this rule is when you use an API (such as file open mentioned before) that throws for pretty common error cases you want to ignore.

Another thing I don't like with exceptions is the fact that you (in C++ and C#, Java is better here) get no help from the compiler to know what types of exceptions a function may call. So in C++ and C# you may think you catch everything you need but you really don't which leads to unwanted behavior in your application. It is just too easy to get into a situation where you think a number of lines are going to be executed but they're not for some exception.

However if you use return codes (as you would in a C program) you get your code cluttered with "if (previous called failed) handle error" which hides what the code really does. This can be hidden using macros to handle errors (ex: result = DoSomething ON_FAIL_RETURN(result); ). And if there is no error handling it is hard to know what happens when the next line is executed even though there was an error.

Using exceptions is also a kind of "I failed and I hope somebody else somewhere can handle it" while the use of return codes defines a clear contract "I failed and you who called me must handle it". So even though exceptions are convenient, return codes feel more defensive, i.e. are easier to get right resulting in less bugs but sometimes at the cost of less clear code. As usual the mix of both approaches is probably the best. But there are more alternatives. If you use adverse as described by Feathers I'm prepared to accept exceptions to a much larger degree because they're being handled immediately so it reminds of the return code approach.

Remember to allocate memory just in case you run out of memory

cellfish — Tue, 11 Aug 2009 07:04:00 GMT

Today I read this blog post about how all .Net applications create three exceptions upon start; System.ExecutionEngineException, System.StackOverflowException and System.OutOfMemoryException. The reason is that if these are not allocated from the start, they cannot be created when they occur. This reminded me of when I was writing high performance daemons in C a few years ago.

In those daemons I did a number of things to prepare for the event of memory starvation. First of all I allocated some memory (a few Kb if I remember correctly). If the daemon ran out of memory it was suspended for up to a second and the memory allocation was tried again. Typically I did a handful of retries and if they all failed I released the preallocated memory, logged the error and terminated the process.

The reasoning behind this strategy was based on three assumptions. First of all, if a process cannot allocate memory it is because some other process is leaking memory (or is just using a lot of memory). Second assumption is that the offending process will terminate fairly quickly because of this. Last assumption is that if the offending process does not release memory quick enough it might be the current process that is the problem so it must terminate to let other processes proceed normally. But before termination we release some preallocated memory so that we have enough memory to log the problem.

So what about multi-threaded daemons? If one thread releases some memory another might take it all before we get the chance to log the problem. Well, in my case all daemons were single threaded. If I needed "threads" (which was rare) I forked. So that was not a problem I had to consider.

Fun introduction to F#

cellfish — Wed, 13 May 2009 01:49:00 GMT

There is a very funny introduction to F# available here. So if you want an introduction to F# and/or a few laughs you should watch it.

Refactoring for dummies

cellfish — Mon, 03 Nov 2008 15:13:00 GMT

I was recently looking at a web-cast and it was not related to refactoring at all, but the presenter said something about refactoring that just blew my mind. The code he started with looked something like this:

public ClassD GetD()
{
    ClassA a = new ClassA();
    ClassB b = a.GetB();
    ClassC c = b.GetC();
    ClassD d = c.GetD();
    return d;
}

He then had the nerve to refactor for better performance into this:

public ClassD GetD()
{
    return (new ClassA()).GetB().GetC().GetD();
}

The only thing he did was make the code harder to read. If you use a disassembler like this one to actually look at the generated code. And yes there is a difference in the number of lines of IL that is generated but I feel confident enough that those differences will be removed when the code is compiled to native code before execution. So the only thing accomplished by this refactoring is that the code is harder to read (original example had much longer method names) and the possibility to say "look how easy this is to use, it's only a single line of code". hate to break this to you but I can write anything and everything on a single line if that is important for you. But that doesn't make it better.

Don't refactor for performance unless you know you have a performance issue. Don't refactor to get fewer lines of code. Refactor to remove duplicate code and to make the code easier to understand, not making it harder to understand.

Beginners should not use LINQ

cellfish — Fri, 17 Oct 2008 20:01:00 GMT

When I first heard of LINQ I got really scared. I could see that it was a very powerful tool but also a tool that would be easy to abuse. Most experienced developers tend to agree that putting SQL statements into your logic or even GUI code is a bad design. Beginners tend to realize this pretty soon too. But with LINQ we get the opportunity to do the same kind of bad design once again. And since it is ".Net code" rather than "SQL statement" I had a fear that it would take longer before the beginners learned their lesson. And why do I care? I don't know. Guess I'm just one of those guys who want everybody to do a good job.

Since LINQ was introduced I have not really seen LINQ in action very in any real code so I kind of forgot about this. But then I read this. Looks like I was right. LINQ is being abused just in the way I feared. But I'm happy to see that a person who I've heard speak warmly about LINQ so many times finally points out how LINQ can be your gate to bad design. And remember to read the comments too when you follow the link above. The topic unfolds...

UPDATE: Not only did the topic unfold in the linked thread. It unfolded here. If you just found this page I strongly suggest you read all the comments.

Exit Mocks. Enter Stubs!

cellfish — Tue, 14 Oct 2008 12:13:00 GMT

Since I'm not a fan of mocks I guess my prayers have been heard. Microsoft Research will soon release a stub framework. That's right. Stubs and not mocks! It is part of Pex that I have mentioned before. And you don't need to use Pex if you don't want. You can just use the stub framework by it self.

The new stub framework can currently be used to stub interfaces. It creates the stubs by generating code. At first this scared me since I feared it would not regenerate the stubs when the interface changed (which might happen quite common when creating the interface using BDD). But it works just fine and detects changes in the assembly and regenerates the stubs. Very convenient.

Another convenient thing is that it supplies default implementations for methods if I want. The default is to throw an StubNotImplementedException but I can change that and return default values (null, 0, empty string etc) if that is what I want. And the change can be made globally for all stubs created after the change or for a single stub object.

So how does this work? Consider the following interface:

public interface IMyInterface
{
    int DoStuff();
}

I just tell the stub framework to generate stubs for the assembly containing the interface and it will generate a new namespace with the stubs. If IMyInterface is part of MyNamespace the stub framework will create a new namespace MyNamespace.Stubs with a class SMyInterface. Now we want to make a test. The test below doesn't really make since since it tests the stub instead of something using the stub, but I want to show the code that makes the stub work without the surrounding stuff so bare with me...

void TestStub()
{
    MyNamespace.Stubs.SMyInterface o = new MyNamespace.Stubs.SMyInterface();
    MyNamespace.IMyInterface i = o;
    Assert.Equal(42, i.DoStuff());
}

Now the test will fail since the stub will throw an exception since the stub is not implemented. Let's use the default implementation:

void TestStub()
{
    MyNamespace.Stubs.SMyInterface o = new MyNamespace.Stubs.SMyInterface();
    o.DefaultStub = Microsoft.Stubs.DefaultStub<MyNamespace.Stubs.SMyInterface>.DefaultValue;
    MyNamespace.IMyInterface i = o;
    Assert.Equal(42, i.DoStuff());
}

Still a failure since the stub returns zero for DoStuff(). Let's stub that method.

void TestStub()
{
    MyNamespace.Stubs.SMyInterface o = new MyNamespace.Stubs.SMyInterface();
    o.DefaultStub = Microsoft.Stubs.DefaultStub<MyNamespace.Stubs.SMyInterface>.DefaultValue;
    o.DoStuff = (stub) => { return 42; };
    MyNamespace.IMyInterface i = o;
    Assert.Equal(42, i.DoStuff());
}

Now the test passes! I think this new framework is an excellent addition to the developer's toolbox. And I think it is a better starting framework than all the mock frameworks out there. In the few cases that a mock framework is really needed (over a stub framework) you can easily extend your stub to verify behavior in the same way as a mock does. Currently the stub framework have a few limitations such as only being able stub interfaces. But I'll guess we'll have to wait and see what will be part of the release once it is available to the public (when writing this I've been using an internal release available to Microsoft staff only).

My new favorite .Net unit test framework

cellfish — Wed, 24 Sep 2008 11:53:00 GMT

I recently had a chance to really sink my teeth into xUnit.net. Since I've been stuck with CPPUnit for quite some time and working with xUnit.net was a relief. Compared to NUnit I find xUnit much easier and convenient to work with (and compared with CPPUnit it's in a class of it own).

I feel I must give you four good reasons (no particular order) for why I prefer xUnit.net:

xcopy install makes it incredible easy to use it anywhere it is needed and in any form. Even different versions.
No need to mark up fixtures and test suits with attributes. A test method can basically be put anywhere.
No weird assertion names that feels like just a tick in the feature list. A small set of useful asserts.
Testing for exceptions is an assertion and not a test method attribute.

So earlier I suggested you to take a look at xUnit. Now I'm telling you. You won't be disappointed!

The implementation of iterators in C# and its consequences

cellfish — Sat, 23 Aug 2008 09:23:00 GMT

Recently oldnewthing wrote a series av articles on C# iterators. Especially part four is interesting since it describes how iterators can be used to simplify asynchronous code. I'm not a big fan of this kind of exploit of a programming language since there is a risk the code is harder to understand for new developers looking at the code but it is never the less intriguing to read about.

Now you should not skip ahead and read part four first. Read them all in order: one two three four

C# source analysis

cellfish — Sat, 14 Jun 2008 13:45:00 GMT

And if you listened to me and started to write nice looking SQL, maybe you wanna look ate making your C# code look nice too...

Robot competitions

cellfish — Mon, 28 Apr 2008 09:13:00 GMT

Even though I never played crobots, I have always been intrigued by the idea. I even played RoboForge for a few months a couple of years ago. And today I stumbled across a new robot game; RoboChamps. RoboChamps does not seem to be like all other classical robot combat games but introduces a number of robot challenges of which only one has been released so far. And navigating a maze avoiding traps does not sound like much action but I guess when the sumo challenge is released things will get a little bit more interesting. I think I just found myself a new spare time project...

Yet another unit test framework for .Net released

cellfish — Thu, 24 Apr 2008 09:09:00 GMT

Version 1.0 of xUnit.net has been released. So do we need another unit test framework? And I think the answer is yes. There are a number of things that I've found a little bit weird in NUnit and with xUnit.net they have been removed. I definitely think that you should take a closer look at why xUnit.net was written and the comparison with other unit test frameworks. xUnit.net definitely feels like a new fresh wind in the TDD/BDD toolbox.

Selenium the test tool

cellfish — Wed, 09 Apr 2008 21:39:00 GMT

I almost forgot that before the BDD/DDD presentation, there was a presentation about Selenium. I didn't forget it because it was a bad presentation but because the following presentation was so good...

I've never had any good experiences with tools for automatic testing but I must confess that Selenium looks nice. At least if you want to add regression tests to an existing GUI. And it is a web based GUI. So if those two fact apply to you, you should take a look at Selenium I think.

Selenium is good at recording actions and create test code. And it creates test code for unit tests frameworks such as NUnit and a whole bunch of other languages such as Python, Java, Ruby, PHP and more. However there seems to be some stability problems at the moment. According to the presenter (I have not found a link to verify this); Google have more than 51000 selenium tests in their projects. 96% of the tests run with no problem, 2% have problems due to confirmed bugs in Selenium and the last 2% are tests failing where the reason is unclear (Selenium vs the code tested).

This is a common problem I see when I work with open source. Open source applications are typically quite useful and easy to use 99% of the time. But I always tend to end up needing the last percent which is never implemented or have bugs. And the reason for this is usually that no one have bothered to implement the last tricky advanced feature I end up needing. You probably wanna know why I do not sit down and implement that feature and contribute it back to the open source community. Well that is a whole other topic and I will write about that it the near future.