异常与 errno
作为一名 C 程序员,我对异常没有太多经验。我更习惯使用 errno 作为跨多个函数调用传达错误的方法。话虽如此,我没有看到异常的显着特征,所以......
异常和使用 errno 之间的根本区别是什么?
As a C programmer, I don't have much experience with exceptions. I'm rather used to errno
as a means of communicating errors across several function calls. That having said, I don't see the distinguishing feature of exceptions, so...
What is the fundamental difference between exceptions and using errno
?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(6)
这里有很多差异,很难说从哪里开始。
首先,C 中使用的
errno
是一个全局变量;这意味着每个调用errno
设置子例程的例程都必须在执行任何其他工作之前检查errno
(如果它关心正确性)。幸运的是,errno 是线程安全的。C++ 异常会自动展开调用堆栈,直到找到准备处理故障的函数。这意味着在大多数情况下,用户不必显式检查每个调用是否有错误;相反,他们可以在一处收集错误返回。与 errno 不同,C++ 异常可以包含整数以外的值。
There are so many differences here it's hard to say where to start.
First of all,
errno
as used in C is a global variable; this means every routine that calls anerrno
-setting subroutine must checkerrno
before performing any other work, if it cares about correctness. Luckily enough, errno is threadsafe.C++ exceptions automatically unwind up the call stack until they find a function prepared to handle the fault. This means that in most cases users don't have to explicitly check every call for an error; instead they can collect error returns in one place. C++ exceptions can contain values other than integers, unlike errno.
你可以随意忽略errno。必须处理异常情况。
当然,我已经看到了我的份额:
和(Java)
,但至少当你在别人的烂摊子中耕耘时,它会突然出现在你面前。
You can casually ignore errno. Exceptions must be dealt with.
Of course I've seen my share of:
and (Java)
BUT at least that kinda jumps out at you when you're plowing through someone else's mess.
我觉得有必要指出,面对异常编写正确的程序并不容易。您最好对这个主题进行一些研究,也许可以从本周大师开始。只需查找“异常”一词即可。
I feel compelled to point out that writing correct programs in the face of exceptions is not easy. You do well to do some research on the subject, perhaps starting with Guru of the Week. Just look for the word
exception
.1) 异常可以是任何东西,而不仅仅是整数。所以传达的数据是不同的。
2) 异常执行非本地控制流,因此您不必像在 errno 实践中那样在每个级别进行检查,您还可以返回一个指示错误的值,并且每个调用者都会检查是否有错误错误并在发生错误时尽早退出。相反,错误返回执行本地控制流,因此您始终可以准确地看到错误何时通过给定的代码片段传播。这种差异从根本上改变了编码风格。所以沟通的方式也不同。
1) Exceptions can be anything, not just an integer. So the data communicated is different.
2) Exceptions do non-local control flow, so you don't have to check at every level in the way that in practice with
errno
, you also return a value that indicates error and every caller checks for errors and bails out early if one has occurred. Conversely, error returns do local control flow, so you can always see exactly when errors are propagated through a given piece of code. This difference radically changes coding style. So the means of communicating are different too.对我来说,最重要的区别是 errno 很容易被忽略,而异常则很难忽略 - 如果您最终忽略它们,程序将终止......另外,异常是(嗯,应该be) 对象,这样你就可以携带更多有用的信息。
另一个非常重要的区别是,在软件实际上可以做出如何处理问题的明智决定时,可以轻松处理异常,这通常是调用堆栈的几个级别。对于错误代码来说,这并不是那么容易做到的。
To me, the most important difference is that
errno
is easily ignored, whereas exceptions are pretty hard to ignore - the program will terminate if you end up ignoring them... Plus, exceptions are (well, should be) objects, so you can carry more useful information.The other, very important difference is that exceptions can easily be handled at the point where the software can actually make an informed decision how to handle the problem, which is usually several levels up the call stack. That's not that easy to do with error codes.
我发现在嵌入式系统上有用的一种模式是为每个流设置一个错误标志,但前提是设置该标志时尝试的 I/O 操作将立即失败。因此,代码可以执行以下操作:
如果一次尝试获取字节超时,则后续尝试将无条件失败并返回零。没有必要检查每个操作是否失败;如果出现问题,系统最终的表现将大致与 tcp_getbyte() 抛出异常一样,只是速度没有那么快。
One pattern which I've found useful on embedded systems is to have an error flag for each stream, but provide that an I/O operation which is attempted when the flag is set will fail immediately. Thus, code can do something like:
If one attempt to get a byte times out, succeeding attempts will fail unconditionally, returning zero. It's not necessary to check every operation for failure; if something goes wrong, the system will end up behaving roughly as though tcp_getbyte() had thrown an exception, just not quite as fast.