关于控制器返回响应的形式建议
关联帖子:https://ask.buildadmin.com/info/659
帖子正文:
为什么控制器返回响应内容的时候, 不使用return的形式来返回呢?
通过抛出 HttpResponseException
的形式, 框架层面做捕获确实方便很多了, 但是把输出响应这种正常行为, 通过抛出一个异常来实现, 多多少少有点让人觉得不舒服.
是因为担心框架使用者开发不规范, 做不到在 控制器的 Action 中正确的 写 return吗? 还是说考虑到后续兼容长驻内存类框架的运行方式, 所以这么干呢?
请大佬帮忙解疑释惑, 这种形式确实让人挺纳闷的.
个人以为, 让其他语言的开发者来看待这种方式, 真的会被人笑话的吧.
以上包含一些个人的看法和观点, 不是对框架作者的攻击, 最后依然要感谢作者的无私奉献.
请先登录
首先感谢老哥的真诚建议:怎么理解其实直接取决于你对异常的理解,
error()
不用说,抛出异常是符合你的直觉的,success()
不符合你的直觉,但是一个请求不能有两个响应不仅仅是开发直觉还是规范(chunk
和SSE
响应除外),所以success()
必须中止程序,无论是否return
,没实现反而有问题,但根据我的片面理解,大多数语言,比如python、java,go
,实现无需return
的success
主要方法应该都是通过exit
或者抛出异常实现,但是exit
明显是不能使用的,请求结束中间件,常驻内存应用等原因,那么抛出异常来实现无需return
的success
和error
在大多数语言中应该都是最好的选择然后就是理解建议了,异常不是非得是个业务层面的异常,你可以将
success
理解为运行时异常
,或者你就单纯的理解为特定异常
,这也很常见,然后是将异常这个概念用于业务逻辑也很常见,比如早期为了避免安装模块时触发vite热更新刷新页面,就会直接抛出一个异常来打断,在当时开发者无法影响vite
热更新,除了抛出异常影响整个js引擎,压根没其他办法,不用纠结于教科书,灵活运用才是关键,你觉得呢?一个可以随时catch
的输出,其实很好用多谢大佬回复。
但是我还是觉得明确的return来返回明确类型的响应实体结束请求处理是一个更好的方案。
而对于说针对相应内容的捕获和再加工,其实也有很多方案,比如框架层添加处理的钩子,或者直接AOP的形式也是可以的。
这些都是我的个人想法哦, 有时候对于代码确实有点强迫症 😂
萝卜青菜各有所爱,没办法满足所有人的需求,而关于更多可能的方案,欢迎提供demo
嗯嗯,明白。理解。我先找时间学学框架代码。😆
- 1
前往