V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  frodez  ›  全部回复第 1 页 / 共 2 页
回复总数  28
1  2  
@diandian666 你看一下 83L 。
37 天前
回复了 LxnChan 创建的主题 Linux 现在有较为轻量且稳定的 Linux 桌面推荐吗
我个人比较看中对 wayland 的支持,毕竟显示效果比 x11 好很多,所以还是 gnome 吧。
debian 不装桌面,在完全无多余后台任务时,空载内存占用就几十 MB 。
41 天前
回复了 hardwork 创建的主题 程序员 c/c++多线程读写问题,怎么反驳?
先保证逻辑正确,再保证实现正确。逻辑上无法保证偏序关系的,就必须使用同步原语来确保其中关键操作的偏序关系,这是逻辑正确的基本要求,无法取消。
53 天前
回复了 CrazyCollin 创建的主题 程序员 秋招 gg,想做开源方向可行吗
要是有实习就好了,可惜导师不放实习。
@FrankHB 我这边情况是,人少的课,且不在老教室上,就好找插座;人多的课,无论是否有插座,都很难赶上,尤其是多节课连轴上的时候几乎不可能赶上;人少的课,如果在没有插座的老教室,那就没办法了。
@marcong95 研一课多,往往连轴转,而且不容易抢到充电插座,所以经常是一上午 /下午没有充电器。光记笔记还好,万一不喜欢调低亮度,加上需要做些稍微重点的工作(比如编译),一上午 /下午就能把电用完了。
我推荐战 X ,amd 的驱动开源,不会出问题的。
@marcong95 你要知道,上课的大教室里充电位置很少的,而且都在边缘不在中间。有些老旧一点的教室甚至没有充电插头。
@pastor 需要,但是是一种更准确的强制措施,因为首先,你不先处理 result 或者 optional (哪怕是直接写上 unwrap )就无法拿到值;其次,反过来看 go 这边,你无法阻止 go 在返回时既返回值也返回 err ,就像楼主代码里的那样。rust 是强制,go 是约定,我是不觉得约定和强制“基本一样”的。
@pastor 但 golang 的问题在于只能约定必须先处理 err ,而无法强制必须处理 err ,相反 rust 哪怕是 unwrap 也是对 err 的处理,虽然不负责任,但至少保证了强制处理 err 。而且 golang 甚至允许既返回值也返回 err 的情况,相反 rust 的 option 和 result 就能根本上避免这个问题。所以 golang 在错误处理这一点上,比起真正先进的语言还有很大差距。
111 天前
回复了 Konys 创建的主题 Go 编程语言 Java 转 Go
@qianxiaoxiao 轮子的使用得看情况,平时大家考虑得最多的是节约工作量,而往往忽略了共用的轮子兼容性和 bug 一般较少的优点。
我个人建议是双主机,一台装 windows 一台装 linux (如果其中一台是笔记本,那最好是笔记本装 windows )。windows 上玩游戏、进行日常 IM 通信,linux 上开发。windows 机器上也可以安装 ssh/vscode remote 之类工具远程到 linux 机器上。这是最简单最不折腾的方案。
@nebkad 我觉得 @kkocdko 的意思其实是跟着发行版的 LTS 版本节奏走,比如 debian 就用 bullseye 不用 sid ,并且尽量使用桌面环境自带全家桶,其他软件也尽量从官方仓库下载安装,而非找一个野 deb/appImage/snap 包,甚至于自己编译安装。如果非要这么做,就进 docker 或者虚拟机里搞。
不要把 32G 版本的价格说成 16G 啊,会误导人的。
134 天前
回复了 yodhcn 创建的主题 程序员 不限编程语言,你认为哪个 ORM 最好用?
rust 的 sqlx ,不过不是 orm 级别的库。
138 天前
回复了 pkupyx 创建的主题 程序员 go 有没有比较合适的异常处理流程方案
@nothingistrue 你恐怕理解错我的意思了,我没有一句话说过非要自己处理错误,甚至哪怕是不应该自己处理的错误也要自己来处理。而且这和我的意思正相反,因为这不是正确的错误处理方式。

至于统一的错误处理逻辑,统一的错误处理逻辑不会导致必然的错误(但也不等于一定正确),但基本上是更方便的。很多程序员往往混淆了正确处理错误和方便处理错误两件事,因此实际的统一错误处理实践,往往就会通向方便但错误的处理模式。

当然,没有统一的错误处理逻辑,每个错误都必须显式地处理,也不等于必然的正确。就像你说的,if err != nil { print } 也是显式的处理错误方式一样。由于显式处理错误的不方便,就会让很多程序员抵触错误处理,这样也会导致错误。

但在我看来,前者与后者相比,后者起码提供了一个正确且良好的基础,只不过容易因为程序员偷懒而败坏基础。而对于前者,方便比正确更重要,这使得它的基础不够牢固。

所以个人认为,错误处理最好的实践应该是在尽可能显式处理错误的基础上,给程序员提供语法糖、胶水方法、linter 之类的工具,让错误处理变得方便。
140 天前
回复了 pkupyx 创建的主题 程序员 go 有没有比较合适的异常处理流程方案
@pkupyx 我个人的建议仍然是优先选择正确性。如果真的可以把错误归类为 95%的不需要自己处理的错误,和 5%的需要自己处理的错误,你可以把前者和后者分开,前者一路返回,后者自己专门处理。

不是非常建议使用 panic 和 recover ,因为它们都是函数级别的跳转逻辑——如果你要在循环中处理错误,使用 panic 和 recover 很可能会导致遗漏。
140 天前
回复了 pkupyx 创建的主题 程序员 go 有没有比较合适的异常处理流程方案
另外,方便地处理错误往往会让程序员有精力正确地处理错误,但不是说方便地处理错误就会让程序员一定能正确地处理错误。另一方面,正确地处理错误在某种程度上可以让错误处理更方便,但跨过了某个分界点后,正确处理错误又不能与方便地处理错误相妥协。所以这必须是一个与实际业务紧密相关的问题,如果不相关,那么你的做法就会既不方便也不正确。
1  2  
关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   1441 人在线   最高记录 5497   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 54ms · UTC 18:55 · PVG 02:55 · LAX 10:55 · JFK 13:55
Developed with CodeLauncher
♥ Do have faith in what you're doing.