Continuing on from yesterday’s post about simplifying exception handling code by using lambdas and continuation-passing style, I’d like to show off some other examples. Another common pattern in code is to generate a value, test it against some condition, and then have an if/else block to execute two other blocks of code dependent on that test.

So, let’s introduce the TryIgnore() and GenerateTest() helper functions with an example (see below for the trivial implementation). I want to generate a full file path for a log file, delete it if it exists, and then enable logging into that file for the later Windows Installer stuff that will be happening. However, if any of that fails I do not want an exception to be propagated because it isn’t critical to the success of what I’m doing.

Here’s the old code: (I’m omitting the code that initializes the tempPath, dwMsiLogMode, and dwMsiLogAttributes values. Assume that tempPath is just "%TEMP%", and the others aren’t really important for this discussion)

const string logFileName = "PdnMsiInstall.log";

try
{
    string logFilePath = Path.Combine(tempPath, logFileName);

    if (File.Exists(logFilePath))
    {
        File.Delete(logFilePath);
    }
}

catch (Exception)
{
    // Ignore error
}

try
{
    NativeMethods.MsiEnableLogW(
        dwMsiLogMode,
        logFilePath,
        dwMsiLogAttributes);
}

catch (Exception)
{
    // Ignore error
}

And the new code, which makes use of the TryIgnore() and GenerateTest() helper methods:

const string logFileName = "PdnMsiInstall.log";

Do.TryIgnore(() =>
    Do.GenerateTest(() =>
        Path.Combine(tempPath, logFileName),
        s => File.Exists(s),
        s => File.Delete(s),
        s => { /* no-op */ }));

Do.TryIgnore(() => NativeMethods.MsiEnableLogW(dwMsiLogMode, logFilePath, dwMsiLogAttributes));

There’s room to make the code even more succinct by inlining the value of logFileName into the Path.Combine() call, and to have an overload of GenerateTest() that doesn’t take an "ifFalse" delegate. Honestly though, I prefer to have my constants sitting in named values. It makes things easier when you’re sitting in the debugger and scratching your head and/or chin.

Here is the full code for my current "Do" class. I hereby release this into the public domain, so do whatever you want with it. There are obviously many other helper functions that could be added, but what I have her is sufficient to get things started. I’ll let you add others as you need them. And remember, my definition of Function has the type parameters in the reverse order that .NET 3.5’s Func delegate has them.

public delegate R Function<R>();
public delegate R Function<R, TArg>(TArg arg);
public delegate void Procedure();
public delegate void Procedure<TArg>(TArg arg);

public static class Do
{
    public static void GenerateTest<T>(
        Function<T> generate,
        Function<bool, T> test,
        Procedure<T> ifTrue,
        Procedure<T> ifFalse)
    {
        T value = generate();
        (test(value) ? ifTrue : ifFalse)(value);
    }

    public static bool TryBool(Procedure actionProcedure)
    {
        try
        {
            actionProcedure();
            return true;
        }

        catch (Exception)
        {
            return false;
        }
    }

    public static Exception TryEx(Procedure actionProcedure)
    {
        try
        {
            actionProcedure();
            return null;
        }

        catch (Exception ex)
        {
            return ex;
        }
    }

    public static void TryIgnore(Procedure actionProcedure)
    {
        try
        {
            actionProcedure();
        }

        catch (Exception)
        {
            // Ignore
        }
    }

    public static void TryCatch(
        Procedure actionProcedure,
        Procedure<Exception> catchClause)
    {
        try
        {
            actionProcedure();

        }

        catch (Exception ex)
        {
            catchClause(ex);
        }
    }

    public static T TryCatch<T>(
        Function<T> actionFunction,
        Function<T, Exception> catchClause)
    {
        T returnVal;

        try
        {
            returnVal = actionFunction();
        }

        catch (Exception ex)
        {
            returnVal = catchClause(ex);
        }

        return returnVal;
    }

    public static void TryCatchFinally(
        Procedure actionProcedure,
        Procedure<Exception> catchClause,
        Procedure finallyClause)
    {
        try
        {
            actionProcedure();
        }

        catch (Exception ex)
        {
            catchClause(ex);
        }

        finally
        {
            finallyClause();
        }
    }

    public static T TryCatchFinally<T>(
        Function<T> actionFunction,
        Function<T, Exception> catchClause,
        Procedure finallyClause)
    {
        T returnVal;

        try
        {
            returnVal = actionFunction();
        }

        catch (Exception ex)
        {
            returnVal = catchClause(ex);
        }

        finally
        {
            finallyClause();
        }

        return returnVal;
    }

    public static void TryFinally(
        Procedure actionProcedure,
        Procedure finallyClause)
    {
        try
        {
            actionProcedure();
        }

        finally
        {
            finallyClause();
        }
    }
}

Many lines of code in C# and other imperative languages are seemingly wasted by dealing with overhead such as exception handling and the like. How many times have you written the following type of code?

string[] fileNames;

try
{
    fileNames = Directory.GetFiles(…);
}

catch (Exception)
{
    // There was an error, like the directory isn’t there.
    // This isn’t an error for us, so just use a 0-length array
    // to simplify our later code
    fileNames = new string[0];
}

foreach (string fileName in fileNames)
{
    … do some processing on this file …
}

The basic pattern is, "try to obtain a value by calling this function, but if there’s an error then use a default value." It’s a lot of code, and it gets tiring and unreadable or unmanageable after awhile. This pattern, which is called the hole in the middle pattern, crops up all the time in imperative programming. The structure of this block of code is consistent, but there’s that little part in the middle that’s always changing. Most of the time we just trudge through the code because we want to get our stuff done, clock out, then go home and drink beer.

C# 3.0 adds a nice feature called lambda expressions, which is mostly syntactic sugar for anonymous delegates. Using them along with continuation-passing style we can write some helper functions that make this type of code much easier to deal with, and more expressive and succinct. In Paint.NET I’m adding a static class called "Do" that will help out with my code:

(Please note that Paint.NET’s "Function" delegate has the type parameters reversed from .NET 3.5’s "Func" delegate. "Func" delcares them in the traditional functional or mathematical ordering, where "F x -> y" is equivalent to "y F(x)". So, my code uses the "y-x" order. I added "Function" before .NET 3.5 added "Func", so let’s not get on my case about the ordering … 🙂 )

public static class Do
{
    public static T TryCatch<T>(Function<T> actionFunction, Function<T, Exception> catchClause)
    {
        T returnVal;

        try
        {
            returnVal = actionFunction();
        }

        catch (Exception ex)
        {
            returnVal = catchClause(ex);
        }

        return returnVal;
    }
}

(Quick digression: You’ll note that I do not assign to returnVal at the beginning of the function. This is a pattern I use quite often, because the C# compiler always does analysis to ensure a variable is assigned to before being used. This lets me make sure I always assign a meaningful value, and don’t miss the assignment in any of my branches or clauses. If I were to immediately assign "null", for instance, but then I forgot to assign a meaningful value to it in some if/else branch, then that error would go undetected.)

Once we have this utility function, the first code snippet simplifies to the following:

foreach (string fileName in Do.TryCatch(() => Directory.GetFiles(…), ex => new string[0]))
{
    … do some processing on this file …
}

Voila 🙂 I’m actually using this code in the setup wizard, as it needs to get a list of files in a directory and then delete them. If the directory doesn’t exist then there’s really nothing to do, but it also isn’t an error, and having the try/catch around the call wreaks havoc on the simplicity of the code. This lets me express that much more succinctly.

There are other patterns you can use, such as passing lambdas for the finally clause, or passing lambdas for various exception types, or even returning the exception for more imperative style processing.

Remember how I said I keep trying to write a blog post about bundleware, but I always get annoyed and it turns into rambling junk? (I mentioned this briefly in my previous blog post)

Well, I just received this email from Yazzle.net or something.

Dear Getpaint, [sic]

I represent Yazzle.net. My company is looking for new business partners to bundle our free bonus software. We want to pay you up to $0.80 for every download you bundle our bonus software with. We pay several of our partners over a thousand dollars a day. We offer products relevant to your site demographics. We believe that you can dramatically increase your revenue and simultaneously improve the experience of the visitors to your website.

Please give me a call at (phone number removed) to discuss or contact me at (removed) on aol instant messenger

Regards,
Joseph Ghartey
*Business Development
Yazzle.net
(contact details removed)

So apparently they’ll pay me "up to" $400,000 per month*. Err, tempting? But honestly, would I really want to do business with someone who thinks my name is "Getpaint?" Anyone who says they’ll pay "up to" a certain amount is probably just using that figure as a bait, and the real payout is probably 10% of that.** Although even $40,000/month is a nice figure.

When you download Paint.NET, you want and you get Paint.NET. I don’t think it’s appropriate to bundle Sudoku and ringtones, that’s just ridiculous to be honest. Plus, I refuse to do business with spyware/adware providers. I have more respect for weed dealers*** (well, as long as they’re like Nancy Botwin from Weeds on Showtime, anyway). If I ever bundle anything with Paint.NET it’ll have to be something that’s actually relevant and useful in the context of Paint.NET type stuff.

* Calculated from a rough average/estimate of 500,000 Paint.NET downloads per month.
** I have no facts to back this up, just good ol’ fashioned cynicism. I’d never heard of Yazzle.net before they e-mailed me.
*** This is not a pro-drug endorsement, I’m just trying to make a point. At least a weed dealer is providing something that the customer actually wants. Spyware/adware is usually snuck on to the user’s system without their honest consent.

Like I stated earlier, I’ve finally started work on Paint.NET v4.0 (yay!). To that end, I’ll be focusing most of my development time throughout 2008 on this effort. There will still be Paint.NET releases in the meantime, as there is plenty of life left in the 3.xx architecture. There are a lot of small features that Paint.NET lacks and needs to catch up on that are feasible even without the changes I am slowly architecting into the 4.0 branch. I’m also hoping and planning to integrate some of the more popular or useful community plugins (with permission of course!).

A major change in the Paint.NET architecture for version 4.0 is the introduction of a pervasive late-binding and inversion-of-control mechanism. At a glance it looks like a localized version of COM: “give me an object that implements this interface, btw I don’t care what concrete class actually implements it” (actually, in COM you quite often do specify which implementation you want, but bear with me).

It isn’t anything revolutionary, but refactoring it into a code base that weighs in at 150,000 lines of code is a lot of work. It’s being very educational to me to go through and see all the poor code choices that have been made over the last 4 years. If only I had been psychic back then, I would have known the right way to do things! 🙂

Consider a line of code to load an image resource:

.     string labelText = PdnResources.GetString(“SomeDialog.SomeControl.Text”);

PdnResources is a static class that contains all the logic for retrieving the string resource from the appropriate language file. However, having this as a static class is a very very bad thing, and this pattern is repeated for many other classes that need to be accessible throughout the application. Any piece of code can load resources, even if it shouldn’t be able to. For example, there is code in the Layer and Document classes to load the default name for a layer, and this is not appropriate for code that is in the data layer of the application. This text should be supplied by whoever is creating the objects, or hooked in at the UI layer somehow instead.

To that end, this code will be moved out of a static class and into a public interface and a concrete, private implementation. A bindings provider (or scope) will serve as the mechanism for accessing it.

public interface IResourcesService { … }

internal sealed class ResourcesService : IResourcesService { … }

bindings.RegisterService<IResourcesService, ResourcesService>();

string labelText = bindings.GetService<IResourcesService>().GetString(
“SomeDialog.SomeControl.Text”);

At first glance, this may not appear to buy much, and is more code that is less expressive. But it allows me several things, including the freedom to move the resource loader, or to hide it from pieces of code (such as plugins, or from the data layer). I can do more granular versioning so that if plugins do need access I can at least continue to change it with more freedom (just introduce a “IResourcesServiceV2” or whatever). I can implement things like pseudo-localization by way of chaining together two implementations of IResourcesService. Logging and fault injection can be made easier, as they can also be implemented as a chained implementation. By “chained implementation” I mean that the normal implementation stays as-is, but a second implementation is registered so that it passes-through method calls while also performing some other service, such as logging or transformation. The primary implementation can then be kept clean and simple.

The “bindings” object would never be available globally or statically. Any object that needs to use it must take it via its constructor. This is proving to be a lot of work to enforce, but I believe it will be worth it. It makes it easier to analyze things like layering and dependency flow if code can’t just magically go and grab resources from static locations, and is instead forced to go through an object that is supplied by its creator/owner. For example, if I don’t want the data layer to be able to load resources, then I simply remove the IResourcesService from its bindings object. The only way to access the concrete class at that point would be via reflection, which is easy enough to detect and combat against.

I plan on extending this pattern to all of the static classes in the SystemLayer assembly as well. Instead of just bluntly calling into the PaintDotNet.SystemLayer.FileSystem static class, for instance, you would ask for the IFileSystemService via your local bindings provider object. The SystemLayer DLL would then have a static class with one function that would be responsible for registering all of the bindings.

This may even make things easier for Miguel de Icaza and his Mono port, Paint-Mono, although it’s too early to tell for certain. Done properly, there could be a PaintDotNet.SystemLayer.NetFxWin32.dll and a PaintDotNet.SystemLayer.MonoLinux.dll, and a simple configuration or command-line switch of some sort would choose which one to use at startup. I’ve paid attention to his blog posts and other documentation and it has brought to light some areas that still need to be separated into the SystemLayer DLL.

And while this could be a boon for Miguel, it’s also good for me and isn’t something I’m necessarily doing to directly help out his porting efforts. What if the differences between the XP and Vista code paths grew so great that I needed two different versions of the SystemLayer DLL? Or, what about a Mac OS version?* Moving to a late binding system and avoiding static classes will make things much, much cleaner. Who knows, maybe I can stuff Windows Forms itself behind an abstraction layer and decouple Paint.NET from it. That’s actually one of the things that the new IndirectUI system in v3.20 has allowed me to practice with: I could port the thing over to WPF or even to a console window, and the effects/plugin code wouldn’t know the slightest difference.

* This should not be taken as an announcement of a plan to release a Mac OS version.

I just recently fixed a bug in Paint.NET where I had inadvertently overridden the OnScroll() method instead of the OnShown() method. The code I added was meant to raise the priority of the UI thread while a dialog was initializing (in its constructor), and then drop the priority back to normal once the dialog was finally visible (in OnShown()). This was shown to improve the snappiness of Paint.NET’s UI because it does a lot of processing in background threads, which was then competing with dialog initialization and initial rendering. Since the reversion code was in OnScroll(), which never gets called, the reversion simply never happens. If I’d done a more careful code review, I probably would have caught this.

The reason it was in OnScroll() is because I typed “override OnS” and then expected Visual Studio to auto-complete the method signature. It did this correctly, but I had already overridden OnShown() and so the next match was OnScroll(). Luckily in this case there was no major negative consequence.

Continuations in C#, as exposed via the yield keyword and “iterator blocks”, is a seriously underused and under-researched feature. In C++, you can use Win32 fibers to accomplish the same, and this is in fact how they are implemented in the .NET 2.0 runtime. Update: They are not implemented using Fibers. Thanks for the clarification James. Learn something knew every day!

Did you know that you can use these to implement blocks of code that can literally jump between threads? Quite useful for UI code so you can avoid using all sorts of tedious synchronization and messaging primitives, and also avoid having to split your tasks into multiple functions. Instead of writing function 1 which kicks off a task on the thread pool, then function 2 that performs the long-running task (load a file, download some data, compute something useful), and then function 3 that executes on the UI thread when that is done and sets some UI flags … you can write 1 function that is hosted by a dispatcher or executor of some sort, and then use “yield return” to spit instructions at it. Need to report progress? No problem. Switch to the UI thread, tell your ProgressBar control what’s up, then switch back to the background thread. “yield return new SwitchTo(Thread.UI)” and “yield return new SwitchTo(Thread.Background)” are going to prove quite handy for Paint.NET v4.0.

I’ve been experimenting with this concept a little bit, and the results are promising. I have a simple application that has a “AsyncImageBox” control that uses continuations. It has one function, “LoadTheImage” which implements all of the logic for establishing a connection with a server, downloading the image, reporting progress in the UI, and hooking up the final image to the UI. When the block of code needs to do something that must be done on the UI thread (report progress), it just switches over to the UI thread and does it. Then it reverts to the background thread. This is all inside of 1 function of code, there is no “queue this to the thread pool” or “invoke this message over to the other thread” or “wait on this mutex” or “set this signal” nonsense. I can use traditional synchronous/blocking code (aka, “easier to write, read, debug, maintain, understand, etc.”) for all of this.

I think MessageBox should be added to the list of banned API’s in Windows. I think it is overused and presents an easy but lazy way for a developer to ask questions that the user shouldn’t have to care about. People never read the text that is presented on them, and as a result the wrong things often happen.

As an example, consider the meeting I had with a CPA today*. I brought along a spreadsheet on a USB stick that detailed some of my finances. While he had it open, he inadvertently made a change to the spreadsheet (not a big deal – it was just a copy). When our discussion and meeting was done, he closed the spreadsheet so that he could return my USB stick. So he clicked on File, and then Exit, and was immediately presented with:

Most of us are used to this dialog and usually know what our answer will be even before we’re asked. We would click “No.” But here’s the interesting thing that I heard him say out loud:

    CPA: “Yes, I want to close it.”

And then he clicked on the “Yes” button. The dialog was asking him to save it, not confirm his intent to close it. But for some reason he assumed the dialog was asking him to confirm his intent instead of serve a warning. I hardly blame it on a lack of intelligence, but rather on the usability of Excel, et. al. and the terrible “Yes, No, Cancel” pattern that [almost] all developers seem to be stuck on reusing.

If a task dialog pattern had been used instead, he may have clicked on the button that corresponded with his actual intent, which would have been to click “No”. For Paint.NET v3.0, I instituted these all over Paint.NET in an effort to improve usability.

In this case, “Yes” is replaced by “Save” and “No” is replaced by “Don’t Save”. It is much clearer what will happen when you click on them – there is less left to be assumed, extrapolated, or guessed at by the user. In the “Yes, No, Cancel” dialog above, it is not really clear what happens when you click “No” or “Cancel” – for the former, the changes are discarded and the application exits. For the latter, the changes are left in memory and the application stays open.

These dialogs require more code, but only because there are 8 string resources and 5 graphic resources to load or prepare. The code itself is still quite clear and easy to read, and easy to duplicate. I have a class called TaskDialog with a static function that takes all the text and graphics and then prepares a WinForms dialog that is shown modally. The button that was pressed is then returned to the caller.

Anyway, this was an interesting real-life story and I thought it was worth sharing.

* Yes, this is a true story! 🙂

That’s a good question. Office lets you move the toolbars and even the menubar around (it’s just a differently rendered type of toolbar). Visual Studio lets you, and the “toolstrip” controls in .NET 2.0 supposedly have the capability. So why, then, doesn’t Paint.NET allow you to move them around or do other customization?

As Raymond Chen would say, “Because the alternative is worse.”

It becomes a usability problem, or at least an annoyance, for the people who don’t want to customize their toolbar*, and this is something I was reminded of just now when I looked over at RSS Bandit and saw this:

Why is my menu bar below the toolbar? Because I accidentally dragged something around. I don’t know when or what.

It becomes a usability and support nightmare because people would lose the toolbars, or otherwise be unable to find features they already found. Do not underestimate individuals’ ability for this! And it’s not about stupidity or intelligence, it’s just about usability. I recently had a reasonably intelligent friend ask me, “Where is that new ‘Fixed Size’ functionality for the selection tool that you’ve been talking about?”, and it was right in front of his face.

It also hinders productive troubleshooting or communication between two Paint.NET users.

Bob: “Just click on X in the toolbar.”
John: “I don’t see it.”
Bob: “It’s kinda on the far-right side. Do you have the latest version?”
John: “Yes I have 3.20.”
Bob: “Umm … is part of the window off-screen?”
John: “No the whole thing is only taking up half my monitor.”
Bob: “Yargh. Did you hide or move the toolbar or is the toolbar off-screen or under some other stuff?”
John: “I don’t know?”
Bob: “Click the Reset Toolbars menu item in the Window menu.”
John: “Hmm. We have another problem. I have no menus either.”
Bob: “I will start using four-letter words from now on. Plug your ears.”

Here’s the conversation without customized toolbars:

Bob: “Just click on X in the toolbar.”
John: “I don’t see it.”
Bob: “It’s kinda on the far-right side. Do you have the latest version?”
John: “Oh there it is! And yeah I have 3.20.”

So, because I do not want an inbox full of people asking me how to fix their toolbars or how to find their features, and nor do I want to have to add complicated self-healing code or a “Reset Toolbars” menu item (that people would still lack the psychic powers to find, mind you!), I have disallowed this type of functionality. The toolbars will only ever show up in Paint.NET in one way. Oh, and I also want people to be able to use the software and not have a need to consult documentation or a support line. Because if users have to do that, then you have failed.**

* According to conventional insight, most people do not customize anything about the software they use.

** I think this insight comes from a blog I’ve read elsewhere but for the life of me I can’t find it.

I want to start working on Paint.NET v4.0, and the time has finally come. I have some wicked ideas on pervasive parallel programming that I am hoping to thoroughly integrate throughout the application*. However, this will take a lot of time to engineer, and may involve significant refactoring or a “spiritual rewrite”. It will take at least a year to complete, if not more.

In the meantime, however, the v3.xx architecture still has some life left in it (duh). My plan is to have new, minor releases of the v3.xx branch throughout the course of 2008 at 6-week intervals. To start, I plan on releasing v3.22 in mid-January. It will have some bug fixes, a performance tweak, and Tom’s “Reduce Noise” plugin. After that, you can expect something like a v3.24 release by March. Maybe I’ll add 8-bit and 24-bit support to PNG or something. I’m not sure yet. It will depend on what the user base is clamoring for of course.

For a freeware like Paint.NET, you cannot just have a year-long gap between releases. You have to keep interest in the project alive which means staying on the front page of sites like Neowin. The project grows by having short, large spurts of press coverage. When I released version 3.0 in January of this year, the short-term increase in traffic was enormous and the smaller but long-term, sustained increase was crucially important.

Other revenue opportunities might present themselves as well, such as developing and selling a “Paint.NET Plugins Pack” for $10 or something. These could provide fuel for more rapid development of the major version 4.0 release.

* I have a lot of thoughts in this area, but so far have not distilled them into short-enough blog posts. It’s one of those, “where do I start?” and “who’s my audience?” problems.

About 30x the traffic that I had yesterday. Fun stuff. The “Slashdot effect” will always amuse me 🙂