ComponentBase needs proper async error reporting

[SteveSandersonMS]

Currently, ComponentBase is hard-coded to deal with async lifecycle exceptions just by logging them to the console. This is understandable (albeit limited) in the WebAssembly case, since the developer console is the only place people are going to look for errors anyway, but it's no good for the server-side execution case.

We might want to have an event on ComponentBase that reports async lifecycle task failures. Then the WebAssembly host can set up a listener that just logs to console, whereas the server-side executor can wire it into the ASP.NET logging system.

[SteveSandersonMS]

Note: when implementing this, be sure to update the unit tests in ComponentBaseTest so that they explicitly check whether any unexpected exceptions are reported and fail if they are. For example, in the tests about cancellation, we need to observe that cancellation of OnInitAsync/OnSetParametersAsync tasks does not get reported as an exception, whereas actual failure of those tasks does get reported as an exception.

[javiercn]

Now that SetParametersAsync we should not do any specific error handling within there for OnSetParametersAsync and OnInitAsync. We should let those errors flow all the way up to the renderer and let the renderer deal with them as appropriate.

Regarding errors happening from IHandleEvent we could change the interface to:

        Task IHandleEvent.HandleEventAsync(EventHandlerInvoker binding, UIEventArgs args)
        {
            var task = binding.Invoke(args);
            // If there is real async work going on, it adds a call to StateHasChanged() after 
            // the async work is done
            task = ContinueAfterLifecycleTask(task);

            // After each event, we synchronously re-render (unless !ShouldRender())
            // This just saves the developer the trouble of putting "StateHasChanged();"
            // at the end of every event callback.
            StateHasChanged();

            return task;
        }

This way errors can flow all the way to the renderer or other component where they can be handled appropriately in a single place.

@SteveSandersonMS Thoughts?

[SteveSandersonMS]

@javiercn

Now that SetParametersAsync we should not do any specific error handling within there for OnSetParametersAsync and OnInitAsync. We should let those errors flow all the way up to the renderer and let the renderer deal with them as appropriate.

That sounds completely reasonable.

Regarding errors happening from IHandleEvent we could change the interface to...

It just so happens that @rynowak was contemplating this last week and started circling around a refinement of the IHandleEvent design. I'm not certain his design reached a conclusion, but when he gets back to looking at it, hopefully it can be made to line up with the requirements for error reporting.

[javiercn]

@SteveSandersonMS For what is worth I'm in support of my proposal 😄. I think it's better if we handle exceptions in one place and the renderer seems to be the best place for it (as it allows for reporting errors to the appropriate environment).