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".