LINQ: Single vs. SingleOrDefault

LINQ With C# (Portuguese)

Like other LINQ API methods that extract a scalar value from a sequence, Single has a companion SingleOrDefault.

The documentation of SingleOrDefault states that it returns a single, specific element of a sequence of values, or a default value if no such element is found, although, in my opinion, it should state that it returns THE single, specific element of a sequence of ONE value, or a default value if no such element is found. Nevertheless, what this method does is return the default value of the source type if the sequence is empty or, like Single, throws an exception if the sequence has more than one element.

I received several comments to my last post saying that SingleOrDefault could be used to avoid an exception.

Well, it only “solves” half of the “problem”. If the sequence has more than one element, an exception will be thrown anyway.

In the end, it all comes down to semantics and intent. If it is expected that the sequence may have none or one element, than SingleOrDefault should be used. If it’s not expect that the sequence is empty and the sequence is empty, than it’s an exceptional situation and an exception should be thrown right there. And, in that case, why not use Single instead? In my opinion, when a failure occurs, it’s best to fail fast and early than slow and late.

Other methods in the LINQ API that use the same companion pattern are: ElementAt/ElementAtOrDefault, First/FirstOrDefault and Last/LastOrDefault.

LINQ: Single vs. First

LINQ With C# (Portuguese)

I’ve witnessed and been involved in several discussions around the correctness or usefulness of the Single method in the LINQ API.

The most common argument is that you are querying for the first element on the result set and an exception will be thrown if there’s more than one element. The First method should be used instead, because it doesn’t throw if the result set has more than one item.

Although the documentation for Single states that it returns a single, specific element of a sequence of values, it actually returns THE single, specific element of a sequence of ONE value. When you use the Single method in your code you are asserting that your query will result in a scalar result instead of a result set of arbitrary length.

On the other hand, the documentation for First states that it returns the first element of a sequence of arbitrary length.

Imagine you want to catch a taxi. You go the the taxi line and catch the FIRST one, no matter how many are there.

On the other hand, if you go the the parking lot to get your car, you want the SINGLE one specific car that’s yours. If your “query” “returns” more than one car, it’s an exception. Either because it “returned” not only your car or you happen to have more than one car in that parking lot. In either case, you can only drive one car at once and you’ll need to refine your “query”.

Visual Studio: Setting Up The Current Project And Run

When I’m building a demo solution I usually have several projects to demo different features.


When I want to run one of the projects, I have to set it as the startup project (either in the Project menu or in the context menu of the Solution Explorer for the desired project) and start it with or without debugging.


I can start any project with debugging using the context menu for that project in the Solution Explorer, but I cannot start the project without debugging.


While preparing for my session at the upcoming Microsoft TechDays 2010, I decided to work around this by creating macros to set the current project as the startup project and start the project with or without debugging:


Sub SetAsStartUpProjectAndStartWithoutDebuggingMacro()
    DTE.ExecuteCommand("Project.SetasStartUpProject")
    DTE.ExecuteCommand("Debug.StartWithoutDebugging")
End Sub

Sub SetAsStartUpProjectAndStartWithDebuggingMacro()
    DTE.ExecuteCommand("Project.SetasStartUpProject")
    DTE.Debugger.Go(False)
End Sub


And I can bind those macros to keyboard shortcuts (Shift+Alt+F5 for starting with debugging and Ctrl+Shift+Alt+F5 for starting without debugging) and add them to a toolbar.

C# Proposal: Compile Time Static Checking Of Dynamic Objects

C# 4.0 introduces a new type: dynamic. dynamic is a static type that bypasses static type checking.


This new type comes in very handy to work with:



Because static type checking is bypassed, this:


dynamic dynamicValue = GetValue();
dynamicValue.Method();


is equivalent to this:


object objectValue = GetValue();
objectValue
    .GetType()
        .InvokeMember(
            "Method",
            BindingFlags.InvokeMethod,
            null,
            objectValue,
            null);

Apart from caching the call site behind the scenes and some dynamic resolution, dynamic only looks better. Any typing error will only be caught at run time.


In fact, if I’m writing the code, I know the contract of what I’m calling. Wouldn’t it be nice to have the compiler do some static type checking on the interactions with these dynamic objects?


Imagine that the dynamic object that I’m retrieving from the GetValue method, besides the parameterless method Method also has a string read-only Property property. This means that, from the point of view of the code I’m writing, the contract that the dynamic object returned by GetValue implements is:


string Property { get; }
void Method();

Since it’s a well defined contract, I could write an interface to represent it:


interface IValue
{
    string Property { get; }
    void Method();
}


If dynamic allowed to specify the contract in the form of dynamic(contract), I could write this:


 


dynamic(IValue) dynamicValue = GetValue();
dynamicValue.Method();

This doesn’t mean that the value returned by GetValue has to implement the IValue interface. It just enables the compiler to verify that dynamicValue.Method() is a valid use of dynamicValue and dynamicValue.OtherMethod() isn’t.


If the IValue interface already existed for any other reason, this would be fine. But having a type added to an assembly just for compile time usage doesn’t seem right. So, dynamic could be another type construct. Something like this:


 


dynamic DValue
{
    string Property { get; }
    void Method();
}

The code could now be written like this;


 


DValue dynamicValue = GetValue();
dynamicValue.Method();

The compiler would never generate any IL or metadata for this new type construct. It would only be used, at compile time, for static checking of dynamic objects. As a consequence, it makes no sense to have public accessibility, so it would not be allowed.


Once again, if the IValue interface (or any other type definition) already exists, it can be used in the dynamic type definition:


 


dynamic DValue : IValue, IEnumerable, SomeClass
{
    string Property { get; }
    void Method();
}

Another added benefit would be IntelliSense.


I’ve been getting mixed reactions to this proposal. What do you think? Would this be useful?