社区里三天两头就有人在争论如何处理前端错误，有try-catch和await xxxx.catch(xxx)两派。恕我直言，都不够优雅。而我认为不处理错误才是最佳的错误处理方式。
业界现有的处理错误方式往往是在业务层处理错误，这会带来以下问题：
所有的请求都有可能发生错误，且有多种错误的可能，要在业务层进行处理，非常繁琐，使得业务人员无法专注于业务。
业务层迫于业务压力，只会专注业务，不会去处理这些错误情况，最终产生BUG。
我说的不处理错误，并不是完全不处理错误，而是在业务层不处理错误，将错误处理放在架构层进行。这样做可以大大减少业务代码中的错误处理逻辑，简化代码复杂度。当错误发生时，不需要修改业务代码，只需要在架构层进行相应的处理工作，这样可以保证业务代码的稳定性和可维护性。
我们看看以下几个典型场景：
当界面初始化时，会发起获取类网络请求。如果是环境错误(断网、超时等)，应该给与错误界面以及重试按钮。其他类型错误，根据错误类型，展示相应的错误界面。就这样的一个基本初始化过程就已经劝退了很多人了，非得是产品测试给压力，才勉为其难地去改。但是我们在架构层进行封装后，业务层只管获取完展示，错误页是由架构层自动做的。
我们看看第二个场景，当Tab切换时，获取类请求。如果是环境错误(断网、超时等)，应该给与错误界面以及重试按钮。其他类型错误，根据错误类型，展示相应的错误界面。已经不想做了，谁来都没用。但是我们在架构层进行封装后，业务层只管获取完展示，错误页是由架构层自动做的。
我们看看第三个场景，当获取下拉选项时发起请求。如果是环境错误(断网、超时等)，应该给与错误提示以及重试按钮（在下拉框上）。其他类型错误，根据错误类型，展示相应的错误界面（在下拉框上）。不干了，另请高明吧。但是我们在架构层进行封装后，业务层只管获取完展示，错误页是由架构层自动做的。
架构层处理错误都有哪些方式
1. 框架给的全局处理错误的方式。
2. 用aop注解处理错误。
3. 用业务组件库处理错误。
总结
在业务层处理错误等于没处理错误，没人肯干。拥有一个好的前端架构，在开发时不用去处理错误，才是稳健、高效的方式。
