ArgumentNullException when returning empty ViewResult

[MartinJohns]

Having the following code:

public class HomeController
{
    public IActionResult Index()
    {
        return new ViewResult();
    }
}

Results in an ArgumentNullException:

ArgumentNullException: Value cannot be null. Parameter name: viewData
Microsoft.AspNet.Mvc.ViewFeatures.ViewExecutor.<ExecuteAsync>d__1.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
Microsoft.AspNet.Mvc.ViewResult.<ExecuteResultAsync>d__24.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
Microsoft.AspNet.Mvc.Controllers.FilterActionInvoker.<InvokeResultAsync>d__53.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
Microsoft.AspNet.Mvc.Controllers.FilterActionInvoker.<InvokeResultFilterAsync>d__52.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
Microsoft.AspNet.Mvc.Controllers.FilterActionInvoker.<InvokeAllResultFiltersAsync>d__51.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
Microsoft.AspNet.Mvc.Controllers.FilterActionInvoker.<InvokeResourceFilterAsync>d__46.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
Microsoft.AspNet.Mvc.Controllers.FilterActionInvoker.<InvokeAsync>d__41.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
Microsoft.AspNet.Mvc.Infrastructure.MvcRouteHandler.<RouteAsync>d__6.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
Microsoft.AspNet.Routing.Template.TemplateRoute.<RouteAsync>d__27.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
Microsoft.AspNet.Routing.RouteCollection.<RouteAsync>d__9.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
Microsoft.AspNet.Builder.RouterMiddleware.<Invoke>d__4.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
Microsoft.AspNet.Diagnostics.DeveloperExceptionPageMiddleware.<Invoke>d__6.MoveNext()

Running on the latest version:

• Microsoft.AspNet.vc.6.0.0-rc1-15954
• dnx-coreclr-win-x64-1.0.0-rc1-15798

In an older version this still worked.

[rynowak]

I was having a discussion about this with @MartinJohns in jabbr, and he's saying that this worked in earlier builds before we added argument validation.

Maybe it was dumb-luck that it worked before, but this would be convenient for POCO controllers. It's odd to require view data to be explicitly managed by the user when they are using view models for everything they show on the view.

[Eilon]

@rynowak I think this could at a minimum be changed to fail a bit more gracefully by perhaps failing earlier with a better error. But do you feel that some un-set values could just be silently ignored for scenarios such as POCO controllers?

[rynowak]

That's what I'm suggesting - if you're not directly using a feature like ViewData - the system still needs it (HtmlHelpers), but we shouldn't require you to plumb it through for us.

[Eilon]

Ok so pass in a dummy ViewData if it isn't there?

[rynowak]

yes

[rynowak]

Similar with temp data also if we can

[Eilon]

[A-Za-z]{4}Data?

[ryanbrandenburg]

Closed in #3310