Contract Killers

20 July 2010 08:19

Seriously, is this the most succinct way of expressing this?

[InheritedExport]
[ContractClass(typeof(RequestFailureContract))]
public interface IRequestFailure
{
    string FailureMessage { get; }
}

[ContractClassFor(typeof(IRequestFailure))]
public class RequestFailureContract : IRequestFailure
{
    public string FailureMessage
    {
        get { 
            Contract.Ensures(Contract.Result<string>() != null);
            return null;
        }
    }
}

Personally, I would prefer to write this:

public interface IRequestFailure
{
    string! FailureMessage { get; }
}

If you're currently thinking there's something very wrong with code contracts in C# you'd be right.  What's wrong is that code contracts aren't actually a language feature.  They're implemented as a post-compilation rewrite.  Don't get me wrong, it's really impressive that they achieved it this way, and they're still an improvement on what went before, but I can't help feeling they lost sight of the ultimate goal on this one.  Worse, enforcing code contracts is achieved by a DevLabs download that's feature-locked to particular versions of Visual Studio.  I'm pretty sure I missed the part of the Liskov Substitution Principle that said "This doesn't apply if you happen to be running Visual Studio Professional".

Comments
No comments posted yet.
Something to add?

Talking sense? Talking rubbish? Something I'm missing? Let me know!

Fields denoted with a "*" are required.

 (will not be displayed)

 
Please add 5 and 1 and type the answer here:

Preview Your Comment