The CCR (Concurrency and Coordination Runtime) is out – apparently!

It seems that the CCR I’d been waiting for is now out, and has been for a while. Unfortunately, as far as I can tell it’s only available as part of the Microsoft Robotics Studio. It falls under the same licence as the Robotics Studio, and can be used in commercial apps (for a fee, I believe) - but why on earth isn’t it available as a standalone download with a simple free licence? Robotics Studio 1.0 is a nearly 50MB download, which is absurd if you’re only after the CCR.

It’s relatively little wonder that when searching for the CCR the most common hits are still for the Channel9 videos. I only found the download due to a helpful post in the newsgroups, and I already knew about the existence of the CCR beforehand. Anyone who is interesting in threading but happened to have missed the earlier videos would be forgiven for never hearing about the CCR.

Can you imagine if MS had bundled WCF or WPF as part of an “online games SDK” or something similar? It’s bizarre.

Come on, MS. Give the CCR a proper home, a proper download, and I suspect it’ll get some real momentum.

Sheer Evil: Rethrowing exceptions in Java

This morning, I was looking through some code and I was annoyed (yet again) at Java’s exception hierarchy, particularly when it comes to checked exceptions. Just as a reminder, everything that can be thrown in Java derives from Throwable. The predefined direct subclasses are Error and Exception. (You can derive from Throwable directly yourself, but I’ve never seen anyone do it, thank goodness.) Exception, and any class deriving from it, count as a checked exception – one that you have to declare if your method might throw it. Oh, except for RuntimeException, and its descendants such as NullPointerException. Blech.


This is really painful in some situations. In particular, the code I was looking at wanted to catch everything, act on it, and then rethrow it. My method was declared to throw IOException, and without the catch block everything compiled fine, so I knew that nothing I was calling should throw any checked exceptions other than IOException. However, rethrowing the exception is tricky – because the compiler doesn’t know what you’re up to. I ended up with this foul code:


try
{
    // Stuff here
}
catch (Throwable t)
{
    // Log the error (or whatever)
            
    // Now rethrow
    if (t instanceof IOException)
    {
        throw (IOException) t;
    }
    if (t instanceof RuntimeException)
    {
        throw (RuntimeException) t;
    }
    if (t instanceof Error)
    {
        throw (Error) t;
    }
    // Very unlikely to happen
    throw new RuntimeException(t);
}
finally
{
    // More stuff here
}

Nasty, isn’t it? It would be lovely to somehow tell the compiler that you know there won’t be any other kinds of checked exceptions thrown, just rethrow the original, it’s all right guv, you can trust me, honest.


Well, apparently you can’t really trust me. Not since the hack I worked out this morning. You see, exception checking only occurs at compile time. So, let’s define a really harmless little class called ExceptionHelper:


public class ExceptionHelper
{
    /** Private constructor to prevent instantiation */
    private ExceptionHelper()
    {
    }
    
    public static void rethrow (Throwable t)
    {
    }
}

Nothing nasty going on, is there? So the compiler won’t mind at all if I change the original code to:


try
{
    // Stuff here
}
catch (Throwable t)
{
    // Log the error (or whatever)
            
    // Now rethrow
    ExceptionHelper.rethrow(t);
}
finally
{
    // More stuff here
}

The only trouble is, it doesn’t rethrow the exception any more, regardless of the name of the method. But as I suspect you’ve guessed by now, once we’ve satisfied the compiler, we can change ExceptionHelper.rethrow slightly:


public static void rethrow (Throwable t) throws Throwable
{
    throw t;
}

Recompile ExceptionHelper but not the calling code and we achieve exactly what we want – it will rethrow whatever exception we ask it to, and we’ve fooled the compiler into not worrying about the potential consequences. Of course, this means we could change the code in the try block to something which throws a completely different checked exception, and we’d never know until it happened – the compiler couldn’t help us. The workaround for this is to temporarily remove the catch block and see whether or not the compiler complains.


I’m not actually suggesting anyone should do this, despite a certain appeal in terms of simpler, more readable code in the catch block. A hack like this is horrible, evil, awful. Which is why I had to share it, of course.