Compilation error with C++ Metro App Tutorial - task continuation

Question

I am working through the "Tutorial: Create your first Metro style app using C++" on msdn (link). And shortly into "part 2" of it, I am running into an error. I'm running this on a Windows 8 VM Release Preview (May 31st) with the Visual Studio 2012 Release Candidate (the latest).

Where I'm at is in the code section after adding the 3 new metro pages, the ItemsPage, the SplitPage, and the new "DetailPage". Adding those went fine, but when I add the code directly below, in the section labeled "To modify the asynchronous code that initializes the data model" it creates two copies of the error below:

error C2893: Failed to specialize function template ''unknown-type' Concurrency::details::_VoidReturnTypeHelper(_Function,int,...)' c:\program files (x86)\microsoft visual studio 11.0\vc\include\ppltasks.h   404 1   SimpleBlogReader

Then I took out all the code from that section and started adding it a piece at a time to find out where the error "really" was, as I obviously hadn't modified that standard header file. It turns out it's in the task chain in the App::InitDataSource method:

SyndicationClient^ client = ref new SyndicationClient();   

for(wstring url : urls)
{
    // Create the async operation. 
    // feedOp is an IAsyncOperationWithProgress<SyndicationFeed^, RetrievalProgress>^
    auto feedUri = ref new Uri(ref new String(url.c_str()));
    auto feedOp = client->RetrieveFeedAsync(feedUri);

    // Create the task object and pass it the async operation.
    // SyndicationFeed^ is the type of the return value
    // that the feedOp operation will eventually produce.       

    // Then, initialize a FeedData object with the feed info. Each
    // operation is independent and does not have to happen on the
    // UI thread. Therefore, we specify use_arbitrary.
    create_task(feedOp).then([this]  (SyndicationFeed^ feed) -> FeedData^
    {
        return GetFeedData(feed);
    }, concurrency::task_continuation_context::use_arbitrary())

        // Append the initialized FeedData object to the list
        // that is the data source for the items collection.
        // This has to happen on the UI thread. By default, a .then
        // continuation runs in the same apartment thread that it was called on.
        // Because the actions will be synchronized for us, we can append 
        // safely to the Vector without taking an explicit lock.
        .then([fds] (FeedData^ fd)
    {
        fds->Append(fd);

        // Write to VS output window in debug mode only. Requires <windows.h>.
        OutputDebugString(fd->Title->Data());
        OutputDebugString(L"\r\n");
    })

        // The last continuation serves as an error handler. The
        // call to get() will surface any exceptions that were raised
        // at any point in the task chain.
        .then( [this] (concurrency::task<SyndicationFeed^> t)
    {
        try
        {
            t.get();
        }
        // SyndicationClient throws E_INVALIDARG 
        // if a URL contains illegal characters.
        catch(Platform::InvalidArgumentException^ e)
        {
            // TODO handle error. For example purposes
            // we just output error to console.
            OutputDebugString(e->Message->Data());
        }
    }); //end task chain

I took out the lambdas one at a time (and put in the semicolon so it'd compile), and if I have the first two, it's fine, but the last one in the chain causes an error. But if I create_task just the last one, it compiles. Or if I do it with the first and third it compiles. Or with just the first two.

Is the problem the second lambda? Is the header library getting confused on the void return type? Or is it something else? Working on this theory, I modified the "final" handler declaration to this:

        // The last continuation serves as an error handler. The
        // call to get() will surface any exceptions that were raised
        // at any point in the task chain.
        .then( [this] (concurrency::task<void> t)

Now THIS compiles. But according to the doc at msdn (here), is this right? There's a section called "Value-Based Versus Task-Based Continuations" on that page that is copied below:

Given a task object whose return type is T, you can provide a value of type T or task to its continuation tasks. A continuation that takes type T is known as a value-based continuation. A value-based continuation is scheduled for execution when the antecedent task completes without error and is not canceled. A continuation that takes type task as its parameter is known as a task-based continuation. A task-based continuation is always scheduled for execution when the antecedent task finishes, even when the antecedent task is canceled or throws an exception. You can then call task::get to get the result of the antecedent task. If the antecedent task was canceled, task::get throws concurrency::task_canceled. If the antecedent task threw an exception, task::get rethrows that exception. A task-based continuation is not marked as canceled when its antecedent task is canceled.

Is this saying that the final continuation for error-handling should be the type of the final .then continuation, or the type of the original create_task? If it's the final (as I did above with void), will this continuation actually handle all above errors, or only errors for the final .then call?

Is this the right way to "fix" their example? Or not?

Answer 1

I think the problem is that you need a return type from the second lambda that will be fed to the third one (see the matching FeedData for the return type of the first task and parameter type for the second). Since the second task does not return anything void seems the correct choice. As you want to use the third to capture errors, you will need to go with concurrency::task<void> (based on the quote).

Also, based on the quote, this final task will get called if antecedent (the second in this case) task failed and will report any errors that happened during its execution when t.get() is called. I'm not sure about the case when the first fails, but you can try what happens by throwing an arbirtary exception from the first task.