Define IErrorBoundary as an internal interface for clarity

Author: SteveSandersonMS

src/Components/Components/src/ErrorBoundaryBase.cs

@@ -11,7 +11,7 @@ namespace Microsoft.AspNetCore.Components
     /// <summary>
     /// A base class for error boundary components.
     /// </summary>
-    public abstract class ErrorBoundaryBase : IComponent
+    public abstract class ErrorBoundaryBase : IComponent, IErrorBoundary
     {
         // This deliberately doesn't inherit from ComponentBase because it's not intended to be
         // subclassable using a .razor file. ErrorBoundaryBase shouldn't be used as a base class
@@ -91,7 +91,7 @@ public Task SetParametersAsync(ParameterView parameters)
         /// <param name="exception">The current exception.</param>
         protected abstract void RenderDefaultErrorContent(RenderTreeBuilder builder, Exception exception);
 
-        internal void HandleException(Exception exception)
+        void IErrorBoundary.HandleException(Exception exception)
         {
             if (_currentException is not null)
             {

src/Components/Components/src/IErrorBoundary.cs

@@ -0,0 +1,23 @@
+// Copyright (c) .NET Foundation. All rights reserved.
+// Licensed under the Apache License, Version 2.0. See License.txt in the project root for license information.
+
+using System;
+
+namespace Microsoft.AspNetCore.Components
+{
+    // Purpose of this interface, instead of just using ErrorBoundaryBase directly:
+    //
+    // [1] It keeps clear what is fundamental to an error boundary from the Renderer's perspective.
+    //     Anything more specific than this is just a useful pattern inside ErrorBoundaryBase.
+    // [2] It improves linkability. If an application isn't using error boundaries, then all of
+    //     ErrorBoundaryBase and its dependencies can be linked out, leaving only this interface.
+    //
+    // If we wanted, we could make this public, but it could lead to common antipatterns such as
+    // routinely marking all components as error boundaries (e.g., in a common base class) in an
+    // attempt to create "On Error Resume Next"-type behaviors.
+
+    internal interface IErrorBoundary
+    {
+        void HandleException(Exception error);
+    }
+}

src/Components/Components/src/RenderTree/Renderer.cs

@@ -394,14 +394,13 @@ private bool TrySendExceptionToErrorBoundary(IComponent? errorSource, Exception
             // Find the closest error boundary, if any
             while (componentState is not null)
             {
-                if (componentState.Component is ErrorBoundaryBase errorBoundary)
+                if (componentState.Component is IErrorBoundary errorBoundary)
                 {
-                    // Force the IErrorBoundary component to clear its output, regardless of any logic inside
-                    // that component. This ensures that all descendants are cleaned up. We don't strictly have
-                    // to do this, since the only errors we handle this way are actually recoverable, so technically
-                    // it would be OK if the old output was left in place and continued operating. However that
-                    // would be a whole new way of keeping components running after failure which we don't want
-                    // to introduce and guarantee to support forever.
+                    // Even though ErrorBoundaryBase always removes its ChildContent from the tree when
+                    // switching into an error state, the Renderer doesn't rely on that. To guarantee that
+                    // the failed subtree is disposed, forcibly remove it here. If the failed components did
+                    // continue to run, it wouldn't harm framework state, but it would be a whole new kind of
+                    // edge case to support forever.
                     AddToRenderQueue(componentState.ComponentId, builder => { });
 
                     try