V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  SuperMild  ›  全部回复第 1 页 / 共 228 页
回复总数  4548
1  2  3  4  5  6  7  8  9  10 ... 228  
@gugu33 不怕的,因为,从度盘的角度看,他们监控到一万个用户共上传了 100 万份加密文件,但,这些文件里哪些是正常加密的,哪些是用我这种方法加密的,他们却不知道。
@ZSeptember 啊,对哦!等泛型来了我就用这招。
@ZSeptember 我写了个 check 函数,日常一些不需要特殊处理的 error 就直接抛出。

func check(err error) { if err { panic(err)} }

貌似不少人都会自己写个类似的函数来粗暴处理,尤其是个人小项目。(当然,被说丑的时候还是无法反驳)
@ZSeptember 这个只能少数服从多数,现在有了泛型,Result 的基本用法已经可以用第三方库来实现,也肯定有人会去做这个库,但是看大家爱不爱用吧,如果非常多人爱用 Result ,应该会有语法糖支持。Go 团队一向很保守。
@Joker123456789

try catch 据说运行效率比较低。

在使用上,try catch 通常更方便,但 try catch 的思想是 “实在有需要的时候才处理错误”,因此通常会留很多错误让它崩。

而 Go 的方式,由于非常显性,提倡 “认真对待每一个 error”,因此按照 Go 的麻烦操作写出来的程序,通常会把可预见的 error 与不可预见的 panic 区分得非常清晰。
@anonymous256

1. 返回值这一点没有变,新语法还是返回值。
2. 错误处理在代码的空间上分离,专门用一个 handleErr 函数来处理错误,非常常见,Go 的 web 框架 Echo 就是这样做的。


@ZSeptember 你的这个意见,上面已经有人提出了,而且我也回应过了,改成 ?,返回类型就变成了 Result ,几乎一切库都需要重构才能使用。目前这个方案已经可以非常方便地返回 Result ,后续可以看社区对 Result 的接受度再增加问号之类的语法糖支持。这是激进决策与谨慎决策的不同,只能说性格不一样,很难讨论对错。
@dotmeow 是指 error 的 unwrap 方法吗?这个完全不影响 unwrap 的呀。
@iseki 原来如此,我刚才误会了。因为你说 “又多出俩关键字来”,后面又有人附和说 “只能开特权加魔法”,所以我误以为批判加关键词了。

至于 make ,确实不优雅,但 Go 的设计理念好像强调实用多过优雅,为了追求简化而放弃了很多东西,是一种选择,有得有失,我认为这个问题可以说喜欢或讨厌,却很难讨论对错。
@iseki
@fengjianxinghun

Go 1 稳定了十年,现在 Go 2 大版本升级才加少量关键词,应该很正常吧?

Java 或 C# 之类的,大版本升级从未加过关键词吗?(而且,大版本升级加少量关键词在语言设计圈会被鄙视吗?感觉应该不至于是这样的风气才对。)
@liuxu 可以暂时先留给第三方库去做,有了泛型之后自己包裹一个 Result 出来也行(想来应该会有人去做这个事,到时直接用就行)
@okayan 我之前没有专门去留意,今天看到 Medium Daily Digest 给我推荐才顺手点开看看。
@Buges

这个设计是兼容 Result 的,比如

```
func foobar(a, b int) Result {
handle err { return NewResult(err) }
}
```

如果彻底抛弃 error 改用 Result ,标准库以及第三方库就要全部重构了,显然是一个非常激进的决策,很难说比现在这个谨慎的决策更好吧。

后续如果社区越来越喜欢用 Result ,倒是再对 Result 提供特殊支持也不晚呀。
@yxwzaxns 那就是风格问题,不是好坏的问题。

一般应该在保持风格不变的前提下讨论,因为讨论风格很容易变成无意义的争吵。
@meiyoumingzi6 感谢指教,看了你说的,我才发现我的帖子有个事情没说清楚。

我这个主要是假设有其他语言经验的人,想用 Python 快速开始做个东西,目的是先把东西做出来,后续再慢慢转换为 Python 的思想。

yaml/toml 有个大优点,就是可以减少字符转义,比如 Windows 文件目录里有反斜杠,用 yaml/toml 可以直接写,比较直观。另外就是我除了要读取内容,还要生成 toml 文件,这方面生成 py 文件就不好办了。


@rpman 我是从 C 入门的,也想过学学 C++,但一直拖着,因为太庞大了,看着有点害怕。
@qyd0801 我考虑不周,现在想改标题了…
6 天前
回复了 MaMimi 创建的主题 分享发现 为什么有些文档的作者这么人上人
一方面,现实生活中,有的人就是对语气不敏感,是无心的,想到什么就说什么,比如专业人士对行外人,可能会来一句“这个事情说深入了你也不懂,我就不细说了”,敏感的人可能听了不舒服,但不敏感的人完全感觉不到有啥问题,有时甚至会说“停停停,你不用说原理我听不懂,直接告诉我操作步骤就行,越简单越好”。

另一方面,人也有不同的性格,有的人很圆滑,或者情商很高,或者很体贴别人的心情。但也有的人棱角比较尖锐,说话可能容易得罪人,但只要他做的是好事,不在背后搞人,也很难指责他什么吧?

就我自己的感受,说话容易得罪人的人让我更安心,看起来更安全;反而遇到一些说话毫无破绽的,我会更难和他拉近距离,因为他会藏住情绪,万一我得罪了他他也不会表现出来,这就很可怕。
7 天前
回复了 SuperMild 创建的主题 分享发现 移动硬盘是什么时候降的价?
@AndyZhuAZ 4 年前 2T 是体积比较大的 3.5 寸那种吧?
7 天前
回复了 zwade 创建的主题 问与答 各位的自建笔记里都会记点什么
笔记可以是博客的草稿,以及有些东西不确定要不要发布博客,就先写笔记。

我的笔记的内容非常杂,可以看看我的标签:

https://github.com/ahui2016/localtags/wiki/real-tags

https://github.com/ahui2016/dictplus/raw/main/screenshots/screenshot-04.webp
@yesterday17 用生日日期作为种子算出密钥,这一步不是加密,但用这个密钥加密没人质疑是编码。

而我把密钥镶嵌到密文里,这一步当然不是加密,但从整体上看,有两个特征:

1. 比用生日日期 /电话号码作为种子更安全
2. 仅从密文看,多份密文无法相互对照,没有普通编码的缺点,对于解密者来说只能当作普通加密来破解。
@gitbay 确实是变了,现在需要了,我登录旧帐号去看,确认了旧的还没登记信用卡,但允许我继续用。
1  2  3  4  5  6  7  8  9  10 ... 228  
关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   4082 人在线   最高记录 5497   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 69ms · UTC 03:02 · PVG 11:02 · LAX 19:02 · JFK 22:02
Developed with CodeLauncher
♥ Do have faith in what you're doing.