作者icetofux ()
看板C_and_CPP
标题[问题] 什麽样的"错误"该用例外处理
时间Mon Sep 27 23:20:31 2021
问题(Question)：
除了使用STL或是第三方函式库，我会特别注意需不需要catch例外以外，自己编写
程式大多都还是用旗标或返回值的方式来处理错误，因为我对什麽情况下该使用例
外处理其实没有什麽概念。
比方说书上在介绍例外处理的章节，大多都采用除0错误当成范例，但除0错误可
以藉由运算前检查除数来避免，为什麽会特别为此定义一个例外呢？还有像是
fstream若开档失败，则是藉由检查实例来侦测，为什麽不抛出std::system_error
来作为表示呢？因为没办法从中抓到一个明确的规律或依据，我不太懂得什麽样
的场合或情境，使用例外处理而不是判断旗标或返回值。
请问关於这部分是不是有什麽技巧或经验可以请各位先进提点一下呢？
谢谢。
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 1.169.112.157 (台湾)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/C_and_CPP/M.1632756033.A.4F8.html
1F：推 Schottky: 除以 0 会产生 interrupt 那跟 CPU 内的除法器设计有关 09/28 00:02
2F：→ Schottky: 也有一些浮点除法器会直接除出无限大或 NaN 给你就结案 09/28 00:04
3F：→ Schottky: 我自己写 library 也不用例外机制而用传回值表示 09/28 00:07
4F：→ Schottky: 因为我希望他在 C 和 C++ 都能通用 09/28 00:07
5F：→ Lipraxde: 你说的「例外处理」，指的是 C++ 的 exception，还是指 09/28 00:18
6F：→ Lipraxde: 另外写 code 处理？还有「例外」，是哪种类型的例外？ 09/28 00:18
7F：→ icetofux: 使用try、catch、throw语法的例外处理 09/28 07:13
8F：推 ddavid: 对exception的态度其实人人不同，没有统一规则 09/28 11:33
9F：→ ddavid: 相对比较中庸的说法是你想得到的错误就直接检查，想不到的 09/28 11:35
10F：→ ddavid: 就留给例外去抓，但即便如此还是很模糊 09/28 11:35
11F：→ ddavid: 比如硬碟坏轨，这是一种可以预想到的错误，但你不可能为了 09/28 11:36
12F：→ ddavid: 想得到这个发生机率相对低的状况，就在所有读写前面都加上 09/28 11:36
13F：→ ddavid: 坏轨检测过了才读写 09/28 11:36
14F：→ ddavid: 另外就是有些语言根本已经把exception内化成一种流程控制 09/28 11:37
15F：→ ddavid: 手段而非单单的错误处理，所以某些地方用起来只是另一种if 09/28 11:38
16F：→ ddavid: ，而且「可能」写起来比较简单，这又是另一种状况了 09/28 11:39
17F：推 pponywong: 大哉问 我觉得是没办法回复的错误 用例外处理 09/28 13:00
18F：→ pponywong: 剩下可以回复 或是可以回传错误传值给使用者的 09/28 13:01
19F：→ pponywong: 用C的错误处理 这是我的习惯 也许别人不是这样 09/28 13:01
20F：推 ddavid: 我是比较不会用能否回复来做为区分，自己的基本概念是预防 09/28 14:20
21F：→ ddavid: 与治疗，你事先写好的判断就是预防它发生或者发生了也不会 09/28 14:20
22F：→ ddavid: 造成问题，所以反而不会有恢复行为。比如事前判断除以零会 09/28 14:22
23F：→ ddavid: 出错，所以提早发现0，直接不除，所以预防了事情直接发生 09/28 14:23
24F：→ ddavid: 治疗则是事情让它发生了，事前没有预料、或者就算预料到也 09/28 14:24
25F：→ ddavid: 无法不让它发生，所以只好让它发生後做一些治疗方案，看要 09/28 14:25
26F：→ ddavid: 尽可能继续跑或至少留些log再死 09/28 14:25
27F：→ ddavid: 所以我的区分标准比较像是「你能否阻止它发生」 09/28 14:26
28F：→ ddavid: 但是因为某些便利性或者语言特性（如Python），我其实也没 09/28 14:27
29F：→ ddavid: 这麽遵守这概念就是，还是很弹性去处理这问题XD 09/28 14:28
30F：→ sarafciel: 某些语言第一个想到的就是那个J开头的XD 09/28 15:30
31F：推 ddavid: Python也是啊，连基本的for loop行为就是一直call 09/28 17:01
32F：→ ddavid: next()直到iterator丢出StopIteration exception而中断 09/28 17:02
33F：→ ddavid: Python也有不少基本跟常用package根本上就完全使用例外来 09/28 17:04
34F：→ ddavid: 回应所有正常完成以外的状态，完全让你被迫使用 09/28 17:06
35F：→ ddavid: 我抱持上面讲到的概念刚从C/C++转而接触到Python想说「靠 09/28 17:06
36F：→ ddavid: ，怎麽满地都是exception强迫使用啊？」结果现在也是用爽 09/28 17:07
37F：→ ddavid: 爽了XD 09/28 17:07
38F：→ a27417332: 我也有类似的疑惑，CppCon有类似的主题在说 09/28 19:34
39F：→ a27417332: 我自己理解是对於pre/postcondition用类assert的机制 09/28 19:36
40F：→ a27417332: 针对逻辑上的失败，可以用expected这种方式 09/28 19:38
41F：→ a27417332: 可能会发生但也不知道怎麽处理(OOM)的就用exception 09/28 19:39
42F：→ a27417332: Herb有提议新的exception机制，感觉Rust做法和他很像 09/28 19:42
43F：→ a27417332: 里面提到因例外发生时效率差太多，所以社群主流都不使 09/28 19:47
44F：→ a27417332: 用 09/28 19:47
45F：→ a27417332: 前面说的针对逻辑上的失败描述不太好，应该说像是开档 09/28 19:52
46F：→ a27417332: 或是把字串变成数字这种任务，通常不会希望因非法字串 09/28 19:52
47F：→ a27417332: 就丢个例外让人处理，因为业务逻辑上本身很有可能发生 09/28 19:52
48F：推 ArdenCho: 可以使用 try catch 的语法来进行错误例外处理，会比 09/28 22:57
49F：→ ArdenCho: 使用 if 还方便许多，而且有些状况是完全没办法使用判 09/28 22:57
50F：→ ArdenCho: 断式来进行错误处理的。 但像您的状况，也可以在执行 09/28 22:57
51F：→ ArdenCho: 除法之前先检查除数。 09/28 22:57
52F：推 shibin: 我是写utility很习惯会throw，却不知道catch後怎麽处理好 09/28 23:25
53F：推 shibin: 已检查出某些状况会导致後续动作无法正常执行 就可以throw 09/28 23:32
想延伸请教一个用例：假如我要存取一个未知长度std::vector中的某个元素，可以先使用size()确认元素位址是否合理再进行[]存取、也可以直接用at()存取当元素不存在会throw std::out_of_range，以语法长度来看其实两者都差不多，但这是明显可预期会发生的异常，例外处理的资源成本也比较多高，是否代表使用前者会比较合适呢？
※ 编辑: icetofux (111.71.102.71 台湾), 09/29/2021 08:40:27
54F：→ sarafciel: 一般是会用前者 不过理由跟你想探讨的错误处理无关XD 09/29 12:38
55F：→ longlongint: 我是写android 程式才有感觉。可是这里是C板XD 10/01 00:04
56F：→ longlongint: 底层太抽象+错误资讯跟回传值想分离的时候好用 10/01 00:05