Aspnetcore: 全局异常处理

所有未处理的异常都应该在 Logger 中结束。 如果您看到其他情况，请告诉我们，我们很乐意进行调查。 查看日志应该是这里的方法。

好的，我的理解是我必须提供自己的 ILogger 实现？ 并且在我的实施中我必须处理异常？ （例如显示通知，在服务器端的文件中写入异常并将其发送到客户端的控制器）
实际上，如果找到的是这个包https://github.com/BlazorExtensions/Logging
不太懂怎么用，看来只能用这个登录控制台了。

但即使使用此扩展程序，如果代码中存在未处理的异常，应用程序也会崩溃。

所以如果我理解，我没有选择用 try catch 包围我的所有代码？

谢谢你的解释

此处列出的任何记录器提供程序： https ://docs.microsoft.com/en-us/aspnet/core/fundamentals/logging/?view=aspnetcore-2.2#built -in-logging-providers 以及社区开发的提供程序（ https://github.com/aspnet/Extensions/tree/master/src/Logging#providers）应该可以工作。

但即使使用此扩展程序，如果代码中存在未处理的异常，应用程序也会崩溃。

对于服务器端 Blazor，未处理的异常应断开电路，但不会使应用程序崩溃。 如果一个块是为了抛出一个你可以容忍的异常，那么try-catch似乎是最合理的继续方式。 如果您确实捕获了任意异常，您打算如何处理未处理的异常？

客户端 blazor 不记录任何异常。 它们只是打印到控制台。 这是来自 WebAssemblyRenderer 的代码

protected override void HandleException(Exception exception)
{
    Console.Error.WriteLine($"Unhandled exception rendering component:");
    if (exception is AggregateException aggregateException)
    {
        foreach (var innerException in aggregateException.Flatten().InnerExceptions)
        {
            Console.Error.WriteLine(innerException);
        }
    }
    else
    {
        Console.Error.WriteLine(exception);
    }
}

此处描述了我发现可以拦截异常的唯一方法
https://remibou.github.io/Exception-handling-in-Blazor/

但我不会称这个异常处理......

我想要一个全局异常处理程序，这样我就可以在没有 catch 块的情况下编写我的代码......

{
   IsLoading = true;
   await SomeAsync();
}
finally
{
   IsLoading = false;
   //force rerender after exception
    StateHasChanged();
}

如果 SomeAsync 方法抛出异常，我的 IsLoading 变量设置为 false，但我的视图不会重新呈现。 您必须在 finally 块中调用 SetStateHasChanged 才能强制视图重新渲染

对于客户端 blazor，我终于在 ILogger 上编写了自己的实现（灵感来自登录控制台的默认实现代码）。
有了这个实现，我可以在我的服务器上调用一个 LoggerController，一个 ILogger 也被注入（但是这一次，它的一个 NLog 实现是注入的，所以我可以在服务器上正确地写入所有异常）

我放弃了全局异常处理的想法，这似乎不是 blazor 的逻辑，将 try/catch 放在任何地方，并注入一个 ILogger在所有组件中。

除非您认为有更好的事情要做，否则您可以关闭此问题。

我认为这是一个缺失的功能.. 当抛出异常时，我还希望有一个集中的地方来捕获所有未处理的异常并做一些事情.. 在弹出窗口中显示它，将其记录在某处，将其发送到服务器或其他任何东西.. 对应用程序状态没有任何损害
类似于 WPF 中的 UnhandledException 事件
https://docs.microsoft.com/en-us/dotnet/api/system.appdomain.unhandledexception?redirectedfrom=MSDN&view=netframework-4.8

ILogger不是已经是那个中心化的地方了吗？

@SteveSandersonMS看看我上面的评论
https://github.com/aspnet/AspNetCore/issues/13452#issuecomment -535227410
异常（在客户端 blazor 中）使用 Console.Error.WriteLine 写入控制台，不使用 ILogger 记录它们。您可以实现自定义 TextWriter 并替换 Console.Error
https://remibou.github.io/Exception-handling-in-Blazor/
但是您会得到一个异常的字符串表示形式。解析包含堆栈跟踪的字符串，并尝试（例如）仅获取异常消息至少可以说很麻烦。
我想获得对异常对象的访问权限，以便我可以进行自己的日志记录（或其他任何事情）

@rborasak感谢您的澄清！

关于这个问题的任何更新？

目前，我的服务器端 Blazor 应用程序在引发异常后刚刚停止响应用户输入。

用 try-catch 覆盖所有代码行不是一个好习惯（也不期望开发人员这样做），如果出现“不可预测”的异常，我们应该有一个通用的处理程序来允许我们：

1.选择是否断路。
2.向我们的用户显示“友好”的 GUI 消息，或者只是将他重定向到通用错误页面。

目前，在未处理的异常之后，应用程序无法通知用户出现问题，用户只能重新运行应用程序（关闭浏览器并再次转到应用程序 URL）或刷新页面并释放所有状态（其中有时很好，但应用程序开发人员应该选择这个）。

@hagaygo非常好的总结！

@SteveSandersonMS请为 3.1.x 里程碑考虑这个！ 请不要将此移至 5.0.0

你好，

当开发人员窗口的控制台中的电路中断时，我会收到这种错误。

我不认为目前可以通知用户在此之后在屏幕上发生错误并要求刷新它而无需手动打开开发人员窗口来检查和刷新页面

@SteveSandersonMS您能否澄清app.UseExceptionHandler()是否适用于服务器端 blazor？

我见过几种情况，我的自定义ErrorHandler没有捕获我的应用程序抛出的异常。 示例代码

Startup.cs ：

public void Configure(IApplicationBuilder app, IWebHostEnvironment env, IServiceProvider serviceProvider)
{
    ...
    app.UseExceptionHandler(new ExceptionHandlerOptions { ExceptionHandler = ErrorHandler.HandleError });
    ...
}

ErrorHandler.cs ：

public static async Task HandleError(HttpContext context)
{
    var error = context.Features.Get<IExceptionHandlerFeature>()?.Error;
    var message = error?.Message ?? "[EXCEPTION NOT FOUND]";        
    return;
}

一个例子是当我的存储库抛出异常时：
The instance of entity type cannot be tracked because another instance with the same key value for {'Id'} is already being tracked

我的 MVC 解决方案正在捕获所有异常，并且它使用类似的 ErrorHandling 实现。

将此移动到5.0版本以提炼此处的特定问题，看看我们是否可以解决其中的一些问题。

对我来说最大的问题是错误界限。 我希望能够使用第三方组件，并且以某种方式将我对该组件的使用包装在错误处理中，这样库中的错误就不会杀死我的整个 Web 应用程序。 现在没有“放置 try catch 的地方” - 整个组件树由 blazor 渲染器监督，如果树深处的任何东西搞砸了，它就会死掉。

+1 此功能。
必须在所有方法中放置 try/catch 块并不是一个合理的方法。

我个人曾经抛出异常来管理业务错误。 在较高的级别上，我捕获异常并根据其类型决定是否必须记录异常、显示给用户以及是否显示完整消息（业务异常）或只是“出现问题”） .

实际上，我发现这样做的唯一方法是创建一个 ComponentBaseEx 类，该类继承到 ComponentBase 并覆盖 OnInitialized(Async)、OnParametersSet(Async)...
不幸的是，即使采用这种方式，我也必须手动管理所有用户的操作（删除客户，...）

你认为
1）可以做些什么？
2）如果是，什么时候？

这是我的场景：使用 Blazor 服务器的 Blazor 桌面/混合应用程序。 一个用户一次登录，并且状态在重新加载后仍然存在。 因此，如果存在未处理的异常，除了重新启动应用程序之外，没有其他方法可以让应用程序恢复到可信赖的状态。 我们需要捕获未处理的异常，显示适当的用户体验，然后关闭。 标准桌面应用模式。

临时破解：我们使用 Serilog 设置了日志记录。 Serilog 有一个 API，可让您过滤所有日志消息并决定是否发出它们。 我们通过检查日志事件在其属性字典中是否有CircuitId键来滥用此 API。 如果是这样，那意味着一个电路已经死了——即，有一个未处理的异常。 我们可以从我们检查的日志消息对象中获取违规异常。 Presto - 您可以在最顶部处理未处理的异常，并且可以随心所欲地处理它。

大家好，和其他人一样，如果您将其移至 .NET 5 里程碑，我真的很担心。
通过重写旧的 silverlight 应用程序在 blazor 上工作了一年后，我想在 5 月/6 月将我的应用程序部署到生产中（当 webasssembly 准备好生产时）。

但是如果没有一种强有力的方法来捕获或至少记录所有意外错误，我肯定无法做到这一点。

请考虑在 5.0 版本之前做一些事情，即使是不完美的（只是一个例外的方法对我来说是可以的，至少我们可以登录......）

非常感谢你！

你好，我和@julienGrd的情况一样
请做一些事情来帮助/指导我们。
问候！

我也一样。

我们已将 Blazor Server 端用于我们所有的开发，并从
旧的 ASP.Net 网页。

2020 年 3 月 3 日星期二下午 12:02 eliudgerardo [email protected]
写道：

你好，我和@julienGrd的情况一样
https://github.com/julienGrd
请做一些事情来帮助/指导我们。
问候！

—
您收到此消息是因为您发表了评论。
直接回复此邮件，在 GitHub 上查看
https://github.com/dotnet/aspnetcore/issues/13452?email_source=notifications&email_token=ANKYSDFSUQ3OTBGWQMRV5EDRFUZ27A5CNFSM4IPQWA62YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENUJXLA#issuecomment-594058
或退订
https://github.com/notifications/unsubscribe-auth/ANKYSDGFCDRMZV2N4NLMOMLRFUZ27ANCNFSM4IPQWA6Q
.

--
安吉·班萨尔

*科学游戏*

目的是您应该能够使用ILogger接口记录所有未捕获的异常。 这意味着您可以插入自己的自定义日志记录系统，该系统对异常信息执行任何操作。

然而，还有一部分我们还没有实现。 这由https://github.com/dotnet/aspnetcore/issues/19533 跟踪。 我们一定会很快完成这项工作。

您应该能够使用 ILogger 接口记录所有未捕获的异常

@SteveSandersonMS我认为我们在这里追求的是一个更通用的API，它只是给你一个未捕获的异常来做我们想做的任何事情_与异常本身。_想象我们想要检查异常并可能以某种方式做出反应，也许发送Raygun 等异常跟踪服务的异常，或根据内容呈现一些 UI。 如果没有这样的 API，我们需要滥用ILogger接口来完成所有这些事情，这很尴尬。 为什么不提供更通用的 API，而不是通过 ILogger 实现来强制所有可能的场景呢？

目的是您应该能够使用ILogger接口记录所有未捕获的异常。 这意味着您可以插入自己的自定义日志记录系统，该系统对异常信息执行任何操作。

@SteveSandersonMS您是否有参考示例在服务器端 Blazor 应用程序中执行此操作？ 我的意图是在记录未捕获的异常后，向用户显示友好的消息。 帮助将不胜感激。 问候。

当出现未处理的错误时， @eliudgerardo Blazor 服务器已经显示了一些面向用户的 UI。 您可以自定义此 UI。 有关它的文档位于https://docs.microsoft.com/en-us/aspnet/core/blazor/handle-errors?view=aspnetcore-3.1#detailed -errors-during-development

@SteveSandersonMS我知道你提到的那个选项，但我担心在那种情况下连接电路被破坏了，我不想用try/catch包装我所有的API调用。 那么有没有办法做到这一点？

@eliudgerardo为什么电路坏了很重要？ 即使在未处理的异常之后，您的目标是否以某种方式让用户继续使用电路？

@SteveSandersonMS我们不希望电路中断！。 如果发生异常（在我们的应用程序或我们正在使用的第三方库中的某个位置），我们希望有一个地方可以显示一个对话框，显示“出现问题 {exception.Message}”并且应用程序将继续工作。 我们对此有部分解决方案，将生命周期方法和我们的方法包装到 try catch 块中，但这很麻烦，并且第三方库存在问题......

@partyelite如果未处理异常，则该电路现在处于未知状态。 我们不能再说它里面的任何资源是否仍然可用，你的安全逻辑是否已经完全执行，或者其他什么。 如果继续使用该电路，则可能会产生未定义的行为，包括潜在的安全问题，鉴于此代码正在您的服务器上运行，这些都是有问题的。

我们为未来考虑的一种可能性是有一个可选的“每个组件未处理的异常”机制。 如果启用此机制，则框架将围绕对组件生命周期方法、事件处理程序和呈现逻辑的所有调用执行其自己的try/catch逻辑。 如果框架在该级别捕获异常，它会认为单个组件已死（并可能在 UI 中将其替换为某种“错误”组件），但不会影响电路其余部分的执行。

您认为这种方法能满足您的需求吗？

我当然喜欢为错误设置一个内置组件边界的想法。

那将是极好的。 但我认为我们仍然需要一个方法（它有一个作为输入参数发生的异常），我们可以覆盖它并对那个异常做一些事情——比如显示一个带有异常详细信息的对话框，或者将异常详细信息发送到将被记录到的服务器DB什么的..
我知道现在可以使用 ILogger 完成类似的操作，但是我们将字符串作为输入参数，并且以字符串格式从异常中获取一些特定数据非常困难。

每个组件的未处理异常陷阱会非常好。 理想情况下，这将是可以在外部和/或某些组件中指定的东西，以便我们可以将 ui 或功能的部分隔离到错误边界中。 主要的必要性是能够用这样的语义做一些事情：

<MyApp>
    <HandleErrors>
        <ThirdPartyComponent />
    </HandleErrors>
    <HandleErrors>
        <SomeOtherComponent />
    </HandleErrors>
</MyApp>

如果其中任何一个组件无法呈现，我们需要应用程序的其余部分继续运行。 它相当于一个富数据桌面应用程序，您在其中显示一些侧边栏或执行一些业务逻辑功能，这些功能失败了，但应用程序不会崩溃并丢弃表单字段中的数据。

在 WPF 之类的东西中，使用严格的视图/模型分离可以减轻这种担忧； 最佳实践是使用 MVVM 或 MVC 或其他任何东西，并围绕由视图触发或更新视图的逻辑进行错误处理。 但是，blazor 惯用的观点过于迫切且容易出错，以至于不合理。 很难编写会导致应用程序崩溃的 .xaml 文件，但在.razor 中，无论是从数据绑定到 ORM 支持的属性还是仅仅因为您编写了

<strong i="7">@if</strong> (mightBeNull.Value) {
    <br>
}

ILogger不是已经是那个中心化的地方了吗？

像@julienGrd一样，我需要一种全局捕获MsalUiRequiredException的方法，这样我就可以将用户重定向到登录以请求其他范围。 在 MVC 中有一个操作异常过滤器可以处理此问题，但 Blazor 没有等效项。

也许ILogger是我应该以某种方式这样做的地方？ 如果是这样，感觉很糟糕。 我的例外是与身份验证相关的例外，因此它是一个跨领域问题，我需要一种不会污染我的整个应用程序的方法来处理它。

@kenchilada我知道添加“全局”异常处理程序会是解决您的问题的快速解决方案，但是无论何时使用该方法，您的代码都会完全失去对正在进行的流程的跟踪。 您无法保存状态，也无法提供不只是丢弃当时正在发生的任何事情的用户体验。 一般来说，在 UI 中放置一个可能触发它的特定 try/catch 会更好，这样您就可以在不丢弃所有本地状态的情况下继续操作。

但是，如果您确实想在“全局”级别处理此问题，那么可以， ILogger是您可以做到的一种方式。

问题是 RenderTreeBuilder 模型无法进行基于 try-catch 的处理。 你可以写

<strong i="6">@try</strong>
{
    <p>@{throw new Exception();}</p>
}
catch (Exception e)
{
    <p>An error occurred.</p>
}

..但它不会显示“发生错误。”，它会关闭整个电路。 你甚至没有得到控制台日志和#blazor-error-ui。

@SteveSandersonMS我在“理论”上完全同意你的观点，但我在一个我不知道如何处理它的特定背景下，也许你会有一些答案。

我从现有的 silverlight 应用程序同步大量代码，我将技术迁移到 blazor，但保持兼容性并在两个应用程序之间共享代码，因为工作量很大，两个应用程序需要在一段时间内并行工作.

所以我的问题是在客户端调用 wcf 服务的 ViewModel 同步，如下所示：
````
公共无效 MyFunction(){
wcfClient.MyFunctionCompleted += MyFunctionCompleted;
wcfClient.MyFunction();
}

私人无效MyFunctionCompleted（对象发送者，MyFunctionCompletedArgs args）{
//结果在这里，还有潜在的异常
//我们必须考虑这段代码不安全所以有办法抓住它
}
````

所以当我在我的 blazor 视图中调用我的视图模型的方法时，做这样的事情是没有用的
private void ButtonClick(){ try{ myViewModel.MyFunction(); } catch(Exception ex){ //i can't catch the exception in the service or happened in the callback } }

所以我不知道如何处理服务返回的异常，或者直接在回调中发生异常，我失去了手。

谢谢你的帮助 ！

在这种情况下，您实际上可以使用 TaskCompletionSource。 假设 MyFunctionCompletedArgs 包含异常或 TResult 类型的值，它会是这样的：

public Task MyFunction() 
{
    var tcs = new TaskCompletionSource<TResult>();
    wcfClient.MyFunctionCompleted += MyFunctionCompleted(tcs);
    wcfClient.MyFunction();
    return tcs.Task;
}

private EventHandler<TResult> MyFunctionCompleted(TaskCompletionSource<TResult> tcs) => (object sender, MyFunctionCompletedArgs args) =>
{
    if (args.Error != null)
    {
        tcs.SetException(args.Error);
    }
    else
    {
        tcs.SetResult(args.ReturnValue);
    }
};

然后在 Blazor 端，等待 Promise 完成：

private async Task ButtonClick()
{
    try
    {
        await myViewModel.MyFunction();
    }
    catch (Exception ex)
    {
    }
}

有许多编程/软件场景。

我从这次讨论中得出的结论是，微软（至少目前）不希望我们将 Blazor 用于“大型”应用程序或 LOB 应用程序，因为他们希望我们在任何地方都放置 try/catch 块。

您也许可以通过这种方式构建“小”应用程序。 （另外，正如我所提到的，这不是一个好习惯）

但是具有许多用例和 10-20（甚至更多）开发人员的 LOB 应用程序不能这样工作。

当然，目前 Blazor 存在更多问题，但在开始构建 POC 后大约 10-15 分钟出现了这个问题。

你好，

说得对。希望微软将在今年晚些时候提供更新。

理想情况下，不可能在任何地方都进行错误处理，当电路中断时，开发人员不会去哪里。 我们是 Blazor 的早期采用者，并且是我公司的一个项目迁移的一部分。

Blazor 中有很多东西需要完善。

感谢和问候，

安吉·班萨尔

科学游戏

来自：Hagay Goshen [email protected]
发送时间：2020 年 5 月 26 日，星期二 12:21 AM
收件人：dotnet/aspnetcore [email protected]
抄送：bansalankit2601 [email protected] ； 评论[email protected]
主题：回复：[dotnet/aspnetcore] [Blazor] 全局异常处理 (#13452)

有许多编程/软件场景。

我从这次讨论中得出的结论是，微软（至少目前）不希望我们将 Blazor 用于“大型”应用程序或 LOB 应用程序，因为他们希望我们在任何地方都放置 try/catch 块。

您也许可以通过这种方式构建“小”应用程序。 （另外，正如我所提到的，这不是一个好习惯）

但是具有许多用例和 10-20（甚至更多）开发人员的 LOB 应用程序不能这样工作。

当然，目前 Blazor 存在更多问题，但在开始构建 POC 后大约 10-15 分钟出现了这个问题。

—
您收到此消息是因为您发表了评论。
直接回复此邮件，在 GitHub 上查看https://github.com/dotnet/aspnetcore/issues/13452#issuecomment-633799650 ，或取消订阅https://github.com/notifications/unsubscribe-auth/ANKYSDATEUMBPN43PYQU2ZDRTM7T3ANCNFSM4IPQWA6Q 。 https://github.com/notifications/beacon/ANKYSDD3JBBDUMUWMZ5NQXDRTM7T3A5CNFSM4IPQWA62YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEXDQHYQ.gif

有许多编程/软件场景。

我从这次讨论中得出的结论是，微软（至少目前）不希望我们将 Blazor 用于“大型”应用程序或 LOB 应用程序，因为他们希望我们在任何地方都放置 try/catch 块。

您也许可以通过这种方式构建“小”应用程序。 （另外，正如我所提到的，这不是一个好习惯）

但是具有许多用例和 10-20（甚至更多）开发人员的 LOB 应用程序不能这样工作。

当然，目前 Blazor 存在更多问题，但在开始构建 POC 后大约 10-15 分钟出现了这个问题。

这也是我们降落的地方。 我们将它用于后端管理界面，但目前它太新奇了，无法用于我们面向客户的应用程序。

@gulbanana感谢您的提示！ 不确定我是否会使用这种代码保持与 silverlight 应用程序的兼容性，但我必须尝试（即使我更喜欢全局异常处理解决方案）

在这种情况下，您实际上可以使用 TaskCompletionSource。 假设 MyFunctionCompletedArgs 包含异常或 TResult 类型的值，它会是这样的：

public Task MyFunction() 
{
    var tcs = new TaskCompletionSource<TResult>();
    wcfClient.MyFunctionCompleted += MyFunctionCompleted(tcs);
    wcfClient.MyFunction();
    return tcs.Task;
}

private EventHandler<TResult> MyFunctionCompleted(TaskCompletionSource<TResult> tcs) => (object sender, MyFunctionCompletedArgs args) =>
{
    if (args.Error != null)
    {
        tcs.SetException(args.Error);
    }
    else
    {
        tcs.SetResult(args.ReturnValue);
    }
};

然后在 Blazor 端，等待 Promise 完成：

private async Task ButtonClick()
{
    try
    {
        await myViewModel.MyFunction();
    }
    catch (Exception ex)
    {
    }
}

这里有点困惑......如果全局异常处理不可行，那么为什么会有产品
对于声称“自动记录所有未捕获的异常”的 blazor？：
https://docs.elmah.io/logging-to-elmah-io-from-blazor/

@rono1您现在可以连接到日志管道并记录异常——但这并不意味着您已经“处理”了异常，只是您可以全局记录它们。 不过，我很感谢您的记录！

我们已将此问题移至积压里程碑。 这意味着它不会在即将发布的版本中使用。 我们将在当前版本之后重新评估积压，并在那时考虑这个项目。 要了解有关我们的问题管理流程的更多信息并对不同类型的问题有更好的期望，您可以阅读我们的分类流程。

我们为未来考虑的一种可能性是有一个可选的“每个组件未处理的异常”机制。 如果启用此机制，则框架将围绕对组件生命周期方法、事件处理程序和呈现逻辑的所有调用执行其自己的try/catch逻辑。 如果框架在该级别捕获异常，它会认为单个组件已死（并可能在 UI 中将其替换为某种“错误”组件），但不会影响电路其余部分的执行。

您认为这种方法能满足您的需求吗？

@SteveSandersonMS这是否正在考虑实施？ 它将带来更好的用户体验和更强大的软件。

对此+1。 我们真的应该将每个事件都包装在try/catch中吗？ 我刚刚陷入了一个兔子洞，试图用一些基本组件来解决这个问题来管理状态，因为这是多么痛苦。

+1也对此。 对于有多个开发人员的大型解决方案，try/catch 方法确实不是一种选择。

我通过使用自定义日志记录提供程序在我的客户端 Blazor 应用程序中解决了这个问题：
https://github.com/markusrt/NRZMyk/blob/master/NRZMyk.Client/ReloadOnCriticalErrorLogProvider.cs

使用记录器作为全局异常处理程序似乎有点奇怪，但到目前为止我还没有找到任何更清洁的方法😞

Blazor 团队肯定需要为此做点什么
请求/问题。

2020 年 10 月 4 日星期日 15:24，Markus Reinhardt [email protected]
写道：

>
>
>

我通过使用自定义日志记录在我的客户端 Blazor 应用程序中解决了这个问题
提供者：

https://github.com/markusrt/NRZMyk/blob/master/NRZMyk.Client/ReloadOnCriticalErrorLogProvider.cs

使用记录器作为全局异常处理程序似乎有点奇怪，但在我
到目前为止还没有找到任何更清洁的方法😞

—
您收到此消息是因为您订阅了此线程。
直接回复此邮件，在 GitHub 上查看
https://github.com/dotnet/aspnetcore/issues/13452#issuecomment-703255415 ，
或退订
https://github.com/notifications/unsubscribe-auth/AEVARXEEHAOU532C26QCGXLSJBZRRANCNFSM4IPQWA6Q
.

谢谢您联络我们。
我们正在将此问题移至Next sprint planning里程碑，以供将来评估/考虑。 当我们计划下一个里程碑的工作时，我们将评估该请求。 要详细了解接下来会发生什么以及如何处理此问题，您可以在此处阅读有关我们的分类流程的更多信息。

对于任何寻找客户端解决方法的人：

function reportError(error) {
  if (DotNet) {
    DotNet.invokeMethodAsync('MyApp.Client', 'NotifyError', error);
  }
}

var exLog = console.error;
console.error = function (msg) {
  exLog.apply(console, arguments);
  reportError(msg);
}

window.addEventListener("unhandledrejection", function (promiseRejectionEvent) {
  reportError(promiseRejectionEvent.reason.message);
});

  public partial class AppLayout
  {
    [JSInvokable("NotifyError")]
    public static void NotifyError(string error)
    {
      //Handle errors
    }
  }

浏览器支持

对于生产应用程序来说，这是一个非常重要的特性，如果在发生未处理的错误时我无法控制应用程序的行为，或者至少能够可靠地记录它，我会感到不舒服。 幸运的是，我确信我们可以利用的 JavaScript 中对此有足够的支持，但是这个差距足以让我质疑这项技术是否真的足够成熟，可以在严肃的应用程序中采用。

我希望在未来的版本中优先考虑这个全局错误处理程序。