背景

用户做一个操作往往对应一个方法的执行，而方法内部会调用别的方法，内部可能又会调用别的方法，从而形成一个调用链。我们一般是在最顶层的方法去加try，而不是调用链的每一层都去加try。

在web开发中，用户的一个操作通常对应一个http请求，常见的mvc中一个controller的action会来执行这个处理。由于asp.net core是基于中间件管道的，很常见的方式就是定义一个“异常处理中间件”，它用try包住后续中间件的执行，在catch中捕获异常，记录日志，并返回一个统一的异常json结构返回给调用方。
一般我们会认为“全局异常处理中间件”是一个兜底的方式，我们仍然应该在action中去try，因为那是具体业务逻辑处理的起点，不过我觉得木有必要，完全可以定义一个UserFriendlyException代表业务逻辑异常，而系统默认的Exception认为是系统级异常，在action的调用链中，不需要try，只是发现不满足业务规则时： throw new UserFriendlyException 即可，而其它系统异常我们完全可以不考虑，最后在“全局异常处理中间件”中判断异常类型，若是UserFriendlyException则直接返回ex.Message给前端，不用做日志记录；系统级异常则应该记录异常堆栈日志，并返回一个友好的异常消息给前端。

Blazor server中的默认异常处理及其问题

在blazor server中，首次请求后服务端和浏览器建立了长连接websocket，后续的浏览器和服务端的交互没有类似http这种请求响应了，那在哪里做全局异常拦截呢？

blazor中提供了ErrorBoundary组件，基本格式如下：

<ErrorBoundary @ref="errorBoundary">
    <ChildContent>
        @Body
    </ChildContent>
    <ErrorContent>
        <p class="errorUI">

标签：BlazorServer,肉夹馍,方法,处理,context,aop,异常,public	

From： https://www.cnblogs.com/jionsoft/p/17783675.html