最近在学习使用 go stars 比较多的库,比如 gin,gorm,go redis 等,单独用一个写段代码,感觉很舒服,挺爽,于是想把他们整合到一块儿,感觉很郁闷,数据库,redis 库底层 error 和业务空都归类为 error,我整合成一个业务框架以后写业务就很啰嗦了,要区分是业务 error 还是底层 error ,总不能把底层 error 抛出来前端显示吧,go 又不提倡 panic ,大家有木有用 go 写业务的,用啥框架,还是自己封装?发现 go zero 是个好东西,大部分代码都可脚手架生成
1
lscho 2023-01-01 00:25:59 +08:00 via iPhone
同感,说到底还是异常处理太恶心
|
2
wangritian 2023-01-01 10:45:00 +08:00
goframe ,大而全方向的,用自带 code 的 gerror 解决
|
3
dacapoday 2023-01-01 11:53:50 +08:00
1. gorm 不是精品,至少是鸡肋。无论其 api 风格还是库的实现,都能看出作者 与 go 本身的设计思想 以及其标准库实现 的对抗,但又不得不迁就的无奈(比如配置连接池,raw sql ,自定义 colum 类型的接口设计)
2. 既然是集成第三方库,必然需要封装,无论是出于统一业务逻辑(比如报错方式),还是可维护性(仅就 go-redis 库,难道直接在业务代码里写 redis cmd ?为啥不封装一个面向业务的方法,将 key, ttl 等细节屏蔽)。 3. 如果是纯写业务,对性能,自定义底层行为,以及 第三方依赖管理 没有需求。应该是选择主流的框架或项目模版,按其文档进行开发。而非仅靠 stars 挑选第三方库并集成 |
4
lvsshuttao 2023-01-01 14:00:17 +08:00
目前使用的是 goframe (2.0) + xorm ,然后自己写的错误处理:1. 非业务代码产生的错误全部写入日志; 2. 业务代码根据需要写入日志(简单的参数错误不写日志)
之前尝试用 go zero 写项目,感觉太麻烦了,可能我这种简单的 CURD 项目不太适合 |
5
janxin 2023-01-01 18:43:43 +08:00
错误要做额外包装方便统一处理
|
6
lookStupiToForce 2023-01-03 11:54:00 +08:00
虽然语言不同,但处理这些非算法的工程事务的方法可以相通
推荐阅读一下这个文章(因为带过多地址会导致多扣铜币,地址经过 base64 编码) Python 工匠: 异常处理的三个好习惯 aHR0cHM6Ly9naXRodWIuY29tL3BpZ2xlaS9vbmUtcHl0aG9uLWNyYWZ0c21hbi9ibG9iL21hc3Rlci96aF9DTi82LXRocmVlLXJpdHVhbHMtb2YtZXhjZXB0aW9ucy1oYW5kbGluZy5tZA== 顺带一提,这个文章出自这位 v 友 piglei ,你可以关注一下他 aHR0cHM6Ly93d3cudjJleC5jb20vbWVtYmVyL3BpZ2xlaQ== |