The advantage of rendering the Error view by calling ErrorController.Execute, as opposed to making an entry in web.config, is that you get to preserve the URL without a browser redirect.

If you think about which scenarios warrant a 404 response a more involved strategy is justifiable:

1. Non-supported controller name – captured by {controller}/{action}/{parameter} rule.
2. Supported controller but bad action – captured by Controller.HandleUnknownAction.
3. Non-supported URL format – captured by the catch-all rule.

Using ErrorController.Execute allows to preserve the URL for all of those scenarios. Now, to trap all unhandled exceptions in order to not show a Yellow Screen of Death, you would need to do some error handling in Application.Error event handler. Something similar is described in this answer.

There is a catch, however. If the anti-XSS features kick in and disallow a URL containing, say, angle brackets, executing error controller from global exception handler will throw an exception resulting in a YSOD.

The best solution i found was to catch the exception when doing Execute and do a browser redirect then. This prevents the runtime from creating a YSOD due to an unhandled exception in the exception event.

IController errorController = ControllerBuilder.Current.GetControllerFactory().CreateController(null, "error");
try {
    errorController.Execute(new RequestContext(
            contextBase, errorRoute));
} catch(Exception) {
    //If we are here it means that the URL is unsafe and the only way to handle it gracefully is to redirect.
    Response.Redirect("~/Error/BadRequest"); //Controller/View pair that returns 400 - Bad Request
}

It’s probably not the best idea to handle 400 error as 404, hence we redirect to a “BadRequest” action in the ErrorController.

Please note that this post is written in April 2010, when the WP7 SDK is only one month old. Most of the issues described here will likely not be a problem in later releases. The defining characteristic of such pre-release SDK is that when you are doing the right thing, everything is OK. When you screw up, it just goes KABOOM! without much explanation.

I spent a few hours of trying to work out why I am getting these run-time errors and so I’ve put together a list of the most painful ones, enjoy.

Using {x:Static ...} Syntax

Problem: {x:Static ...} is not supported in Silverlight.

If you to do something like this:

<DiscreteObjectKeyFrame  KeyTime="00:00:00" Value="{x:Static Visibility.Collapsed}">

You will get an obtuse error at runtime:

A first chance exception of type 'System.Windows.Markup.XamlParseException' occurred in System.Windows.dll
Additional information: 2024 An error has occurred. [Line: 114 Position: 61]

Get used to seeing that error. It’ll happen every time you screw up the XAML. Sometimes it’s more helpful than other times and you get the line number of the offending XAML. The line number, along with the exception text will be available in the Output window:

If you are like me and rarely look at the error window, perhaps you should start now. This particular error doesn’t raise a warning during compilation, but does come up as an error when the file is open in the editor:

Solution: Don’t use x:Static but instead an instance of a type in XAML like so:

    <DiscreteObjectKeyFrame  KeyTime="00:00:00">
        <DiscreteObjectKeyFrame.Value>
            <Visibility>Collapsed</Visibility>
        </DiscreteObjectKeyFrame.Value>
    </DiscreteObjectKeyFrame>

Misspelling Animation Element or Property Name

Problem: Misspelling Animation Element or Property Name

In the below code Storyboard.TargetName is invalid. The project compiles and there are no errors in the error window.

    <ObjectAnimationUsingKeyFrames Storyboard.TargetName="SearchBoxMisspelled" Storyboard.TargetProperty="Visibility">
        <!--animation key frames-->
    </ObjectAnimationUsingKeyFrames>

At run-time, you get this error message:

A first chance exception of type 'System.InvalidOperationException' occurred in System.Windows.dll
An unhandled exception of type 'System.InvalidOperationException' occurred in System.Windows.dll
Additional information: 2213 An error has occurred.

The call stack only tells you that this is something to do with the animation:

System.Windows.dll!MS.Internal.XcpImports.MethodEx(System.IntPtr ptr = 146517008, string name = "Begin", MS.Internal.CValue[] cvData = null) + 0x9d bytes
System.Windows.dll!MS.Internal.XcpImports.MethodEx(System.Windows.DependencyObject obj = {System.Windows.Media.Animation.Storyboard}, string name = "Begin") + 0x6 bytes

System.Windows.dll!MS.Internal.XcpImports.Storyboard_Begin(System.Windows.Media.Animation.Storyboard storyboard = {System.Windows.Media.Animation.Storyboard})
System.Windows.dll!System.Windows.Media.Animation.Storyboard.Begin() + 0x6 bytes

Solution: To resolve this, check your animation element and property names. Unfortunately I haven’t found a way to get at the offending animation frame from the call stack. Would be happy to find out if there is a way.

References’ Dependencies

Problem: “Object reference is not set to an instance of an object” error when debugging and crashes when running without debugger.

After adding a reference library you might start getting this error when you debug the project:

This is caused, as far as I can tell, by your references’ dependencies not being copied to the device. After hours of playing around with this it’s apparent to me that this is an intermittent issue with Visual Studio. It is supposed to work out what all the references’ dependencies are, copy them to the output folder and add them to the manifest file ($(OutputDir)\AppManifest.xaml).

Sometimes that doesn’t happen and the app gets deployed without those dependencies. It will still work, up until the point where a class is referenced from a dependant assembly and that assembly cannot be loaded. I expect this problem to go away in later releases of WP7 SDK.

The error will look something like this:

2024 An error has occurred[Line:  Position: ]
at
System.Windows.Application.LoadComponent
...Rest of the callstack.

Solution: Add all the assembiles that your references depend upon as references to the project. Edit: This error kept happening to me until my coworker pointed out the solution, which led to the “Doh moment of the week.” Solution2: When debugging the project select the project in the solution pane and press F5. Yeah, that simple.

I finally got it but it took a while. The issue, particularly in F#, is that combinators don’t make all that much sense as a substitute for non-recursive functions. After all, the only way to run the combinator recursively is with a recursive function (as in let rec). A different solution might be to use recursive types, but that’s is pretty pointless. There was a great StackOverflow question about that by the way.

What is a combinator

I am getting ahead of myself though. Combinators are a mathematical concept pioneered by Haskell Curry. The essence of combinators is that they allow sophisticated computation by combining simple functions. Hence the term combinator. Combinators allow a recursive algorithm to be written using a function that does not call itself but instead invokes another function that is passed in as one of the arguments.

One distinct characteristic of a combinator function is that all of its variables are bound. That means that the function only depends on its parameters, not any other data structures or function defined elsewhere. Just about the best description of what is a combinator and what isn’t can be found here

let freevar=3 //a variable

let IAmACombinator x = x*2;; //variable x is bound as a formal parameter
let IAmNotACombinator x = x*y;; x is bound but y is free. This is not a combinator

Example

Lets do some examples. An algorithm that I will implement is the sum of arithmetic progression. It’s an algorithm that can really be solved in O(1) time (by using the formula (m+n)*(m-n+1)/2, but it makes for good tail recursion test (i.e. you can blow the stack quite easily, unlike the factorial, which runs out of the integer range at about 15).

This is the normal recursive arithmetic progression function:

let rec progsum x =  
    if x <= 1 then 1 
    else x+progsum (x-1)

Combinator Version

Thanks to F# type inference, the combinator function is pretty the same for any application and only depends on the number of parameters to the worker function.

This is the combinator version of the above function:

//Normal arithmentic progression sum combinator
let rec comb f = f (fun x -> comb f x)
let progworker f x = 
    if x <= 1 then 1 
    else x+f(x-1)
//Use partial application to wrap up the combinator call    
let progCombinator x = comb progworker x ;;

This might need a bit of explaining. comb is a higher order function that takes another function as a parameter and returns a function taking one argument. This returned function is what we actually want – a function taking one parameter and returning something of the same type as the parameter.

In the above snippet progCombinator is a convenient way to partially apply our combinator to the arithmetic progression worker function. We could have just as easily done for a factorial:

let factworker f x = 
    if x <= 1 then 1
    else f(x-1) * x;;
//Use partial application to wrap up the combinator call    
let factCombinator x = comb factworker x ;;

Tail recursion

Tail Call Optimization is an F# compiler feature (and in some cases JIT Compiler feature) where it will transform a recursive function into a while loop if the recursive call is the last statement in the function. Let’s go back to the original arithmetic progression function and see if that is the case:

let rec progsum x =  
    if x <= 1 then 1 
    else x+progsum(x-1)

And it isn’t. Even though it looks like the function call is the last statement of the function, progsum(x+1) will be evaluated before x+progsum(x+1) can be computed. Let’s rewrite it to take advantage of tail recursion:

let progTR x =  
    let rec inner x sum = 
        if x <= 1 then sum 
        else inner (x-1) (sum + x)
    inner x 1;;

So, what happened here? Well, for once we declared a wrapper function and the worker function inside it. This is not strictly necessary, but allows to hide some of the implementation semantics. So, if we can visualize how the original function worked, this is a crude diagram that shows the execution path for x = 4:

progsum 4
->calls progsum 3
  ->calls progsum 2
    ->calls progsum 1
       ->returns 1
    <-returns (progsum 1) + 2
  <-returns (progsum 2) + 3
<-returns (progsum 3) + 4

As you can see the result is computed "on the way out" - i.e. as the function returns. In the tail recursive version we compute the result "on the way in", which allows the recursive function invocation to be the last statement in the function. Here is the diagram:

inner 4 1
->calls inner 3 (1 + 4)
  ->calls inner 2 (5 + 3)
    ->calls inner 1 (8 + 2)
      -> returns 10
    <-returns 10
  <-returns 10
<-returns 10

An interesting side effect of this tail recursive function is the fact that the order in which sum happens is not quite the same as in the original function.

Original:

4 + (3 + (2 +(1)))

Tail Recursive:

((4 + 1) + 3) + 2

Tail Recursive Combinator

So, now that we've gone over combinator functions and tail recursive functions you may ask: "What about tail recursive combinators? Do those exist?". And the answer would be "Yes, indeed, such beasts do exist". Here is the same algorithm implemented as a tail recursive combinator:

let rec combTR f = f (fun x acc -> combTR f x acc)
let progTR f x acc = 
    match x with
    | 1 -> acc
    | x -> f(x-1) (acc + x);;
    
let progCombTR x = combTR progTR x 1;;

Looking at the code, there is nothing groundbreaking there. Just as we converted the original function into a tail recursive function by adding a second parameter, we did the same for the both the combinator function and the inner function.

For more details on tail recursion and different ways to optimise it have a look here and here.

So the trick to get this working as pointed out in the article was to call the function on the pointer or reference of the parameter to the original function, thus cauising a second dispatch.

class A {
  virtual void PublicFunction(B& b) {
    b.PerformFunction(*this);
  }
}

The problem with doing this sort of thing with subclasses of the same base is that we need to allow the possibility of the base class being called with one of its subclasses as a parameter. Luckily we can use forward declarations to define the functions and implement them later on.

class b;
class c;
class a {
protected:
    virtual void doFoobar(a& a2); //do stuff here 
    virtual void doFoobar(b& b2); //delegate to b
    virtual void doFoobar(c& c2); //delegate to c
public:
    virtual void foobar(a& a2) {
        a2.doFoobar(*this);
    }
    friend class b;
    friend class c;
};
class b : public a {
protected:
    virtual void doFoobar(a& a2); //do stuff here 
    virtual void doFoobar(b& b2); //do stuff here
    virtual void doFoobar(c& c2); //delegate to c
public:
    virtual void foobar(a& a2) {
        a2.doFoobar(*this);
    }
    friend class a;
};
class c : public b {
protected:
    virtual void doFoobar(a& a2); //do stuff here 
    virtual void doFoobar(b& b2); //do stuff here
    virtual void doFoobar(c& c2); //delegate to c
public:
    virtual void foobar(a& a2) {
        a2.doFoobar(*this);
    }
    friend class a;
    friend class b;
};
//class a
void a::doFoobar(a& a2)  {
    printf("Doing a<->a\n");
}
void a::doFoobar(b& b2)  {
    b2.doFoobar(*this);
}
void a::doFoobar(c& c2)  {
    c2.doFoobar(*this);
}
//class b
void b::doFoobar(a& a2)  {
    printf("Doing b<->a\n");
}
void b::doFoobar(b& b2)  {
    printf("Doing b<->b\n");
}
void b::doFoobar(c& c2)  {
    c2.doFoobar(*this);
}
//class c
void c::doFoobar(a& a2)  {
    printf("Doing c<->a\n");
}
void c::doFoobar(b& b2)  {
    printf("Doing c<->b\n");
}
void c::doFoobar(c& c2)  {
    printf("Doing c<->c\n");
}

The code is far from an ideal double dispatch solution as it relies on the forward declaration trick to resolve the circular dependency between the subclasses. This means that all the classes that need to have this functionality must be known at compile-time (of the base class). This means the base class cannot be made into a library component.

To explain all the friend declarations. Considering the fact that all the classes a, b and c are tightly coupled as is, I added friend declarations so that the actual worker function is private and cannot be called from the outside.

Everyone kept going on about how fast Chrome after it came out. My experience has been the opposite. A few months back every time I would start Chrome it would sit for half a minute, discovering proxy, I think. It hasn’t really altered my browsing experience once it got started. That was fixed a while back.

Now I have found more issues that actually make it the slower browser out of IE(!!!) and Firefox. Try browsing this site:

24ways.org

Yeah. You can’t scroll for shit.

Fair enough, it’s a bug. That’s OK, we all write bugs. I would have completely not cared if not for yet another Chrome idiosynchrasy that just tipped me over the edge.

The layout that I am working on is largely inspired by 24ways.org, so it has a few semi-transparent elements, which of course don’t work in IE. As a workaround I am using one pixel PNGs with alpha channel. Supposedly this is the way to do it:

.transparent {
  background: url(pngwithalpha.png);
  background: rgba(255,255,255,0.1);
}

What the browser is meant to do is to disregard the first background declaration and use the second if it supports RGBA colours. That’s what Firefox does… But no, Chrome loads those images anyway.

Fair enough, it has quirks. At least it would cache the images, right? WRONG!!!. Unlike Firefox and IE, Chrome would request those image even though you don’t refresh the page. Both IE and Firefox, when you focus on the address bar and hit enter will retrieve the images from local cache. When you refresh, they would do an If-Modified-Since request. Chrome does an If-Modified-Since request regardless.

Actually, I lie. It doesn’t do the request regardless. It will do a status request for images that are visible straight away. If there is a background image that is in a :hover pseudo-class, it will retrieve that one from the local cache. Go figure.

Here is an excellent and very detailed comparison of browser support for transparencies and pngs. Go Firefox!!!

Most of the time I realize that a lot of those pattens is osmething that I have been doing for years without thinking. In fact this inspires me to go through “the list” of all the patterns and do a series of blog posts – “Design Patterns – What you have coded for years is actually an idiom – [insert design pattern here]“.

So, I only just recently found out that the practice of using smart pointers is officially called RAII – Resource Allocation Is Initialization. The Wikipedia article bangs on about ojects being allocated on the stack and exception safety, but in my opinion those considerations are not as significant as the magic of destruction.

The only way this works in C++ is due to deterministic destructors. The magic happens upon destruction, not upon initialization. Any garbage collected language can have Allocation on Initialization, but they can’t guarantee implicit destruction when going out of scope like C++ does.

I also think that that object scope (the fact that it should be on the stack) is somewhat peripheral again. The destructor will get called whenever you explicitly delete the object as well. Whilst this is not strictly automagic destruction, it can be – for example when using collections that are aware of element removal semantics. For example a collection might either call a Release method on a ref counted object or call operator delete on plain old pointer.

So this brings me back to the title of hte post – shouldn’t Resource Allocation Is Initialization be Resource Deallocation Is Destruction? That’s where the magic happens, right?

Then recently I saw some unit tests in a Microsoft article talking about using TDD to create web controls using Model-View-Presenter paradigm. The article itself can be found here http://msdn.microsoft.com/en-us/magazine/cc188690.aspx.

Its crazy! You write twice as much code! Not only that, you have to use this framework to create mock objects and test methods on the interfaces before even writing them (tests before code, doh).

Having said that, I am willing to give TDD for really just one reason. And the reason is that writing tests that independently test the two halves (e.g. View and Presenter) makes you think upfront about the design of the two interfaces a bit more. This, in turn, precipitates the right design faster, without having to write a lot of either UI or business logic code.

The long term advantage is quite obvious and is comes from both Separation Of Concerns principles (whatever shape they come in – MVP, MVC, MVV, MVA) and having unit tests. In some time, if there is a need to rewrite the implementation of any part of the system, the interfaces between them are loosely coupled and testable. The latter, in my opinion, is even more important than the former. Having a testable interface will aid finding the problems in the new implementation more than a “beautifully” designed one.