blocks|key|1024615|text|选择什么样的策略往往是品味的问题。我说的是，选择与你图书馆的客户集成最好的东西。如果采用异常策略，则使用异常。如果他们习惯了错误代码，那就坚持下去。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1024616|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

It is often a matter of taste what strategy to choose. I say pick up what best integrates with the clients of your library. If they adopt exception strategy, use exceptions. If they are accustomed to error codes, stick with it.

blocks|key|1023659|text|断言不是正确的选择。当你有一个不变量时使用断言；一些不应该发生的事情。不要做断言()之类的事情，如果参数是一个错误条件而不是一个不变量，那么它永远不会是空的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1023660|如果是我，我将在接口中使用异常，如果必须的话，如果不使用异常，则通过内部使用的函数来翻译错误代码。在这方面要保持一致(不要为这些东西使用断言)。|1023661|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

assert is not the right choice. Use assert when you have an invariant; something that should never happen. Don't do things like assert() that an argument will never be null if it is an error condition and not an invariant.

If it were me, I would use exceptions in the interface and, if I had to, translate error codes by functions used internally if they do not use exceptions. Just be consistent about it (and don't use assert for this stuff).

blocks|key|986687|text|首先-保持一致！|type|unstyled|depth|inlineStyleRanges|entityRanges|data|986688|第二：|986689|仅仅是对/假是不够的。它必须与错误代码(例如false%2B+getLastError+)相结合。|unordered-list-item|986690|错误代码是快速的，但建立一些基础设施，以方便地将它们转换成字符串。|986691|断言/日志:不，您希望应用程序能够对错误作出反应|986692|异常比错误代码慢，但是很容易用一个困难的控制流来编程.|986693|组合:只有真/假%2B错误代码组合，对于rest+是一致的，意思是:不合并。|offset|length|style|BOLD|986694|entityMap^0|0|0|0|0|0|0|N|4|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|V|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|W|8|@]|9|@]|A|$]]|$1|G|3|H|5|F|7|X|8|@]|9|@]|A|$]]|$1|I|3|J|5|F|7|Y|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|Z|8|@]|9|@]|A|$]]|$1|M|3|N|5|F|7|10|8|@$O|11|P|12|Q|R]]|9|@]|A|$]]|$1|S|3|-4|5|6|7|13|8|@]|9|@]|A|$]]]|T|$]]

First - be consistent!

Second:

<ul>
<li>just true/false is not enough. It has to be combined with error codes (false + getLastError for example).</li>
<li>error-codes are fast, but build some infrastructure to convert them easily into strings.</li>
<li>assert/log: no, you want the application to be able to react on the error</li>
<li>exceptions are slower than error-codes, but easier to program with a difficult control flow.</li>
<li>combinations: only true/false + error codes combine, for the rest BE CONSISTENT which means: do not combine.</li>
</ul>

blocks|key|2512642|text|我建议阅读Boost社区指南+boost.org中的异常和错误处理。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|2512643|entityMap|0|LINK|mutability|MUTABLE|url|http://www.boost.org/community/error_handling.html^0|C|2|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

I recommend reading the Boost community <a href="http://www.boost.org/community/error_handling.html" rel="nofollow noreferrer">guide</a> [boost.org] to exceptions and error handling.

blocks|key|986755|text|其中任何一个都有不同的目的：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|986756|错误代码。异常:异常和错误代码代表了如何处理结果代码的不同成语。异常更健壮--结果代码可以被忽略或丢失.库通常应该强烈区分抛出的异常位置/异常以及何时使用错误代码。充其量，只使用两种方法中的一种。|unordered-list-item|986757|返回true或false：错误代码的专门化。通常情况下，最糟糕的想法--只有在没有好的或坏的报告的情况下才是好的(即malloc返回好的或坏的(=+NULL)+)。|offset|length|style|CODE|986758|断言和日志:这些都是调试技术，不应该用作用户/客户端的报告机制。断言只是说“发生了什么事，我无法处理-我辞职了”。|986759|entityMap^0|0|0|2|4|7|5|1M|6|22|4|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|P|8|@]|9|@]|A|$]]|$1|E|3|F|5|D|7|Q|8|@$G|R|H|S|I|J]|$G|T|H|U|I|J]|$G|V|H|W|I|J]|$G|X|H|Y|I|J]]|9|@]|A|$]]|$1|K|3|L|5|D|7|Z|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|10|8|@]|9|@]|A|$]]]|N|$]]

Any of these have different purposes:

<ul>
<li>error code vers. exception(s): exceptions and error codes represent different idioms of how result codes shout be handled. Exceptions are more robust - result codes can be ignored or lost. A library should usually strongly distinguish where/what exceptions are thrown, and when error codes are used. At best, use only one of both at all.</li>
<li>return <code>true</code> or <code>false</code>: A specialization of error codes. 
Usually the worst idea - only good if there is no more to report than good or bad (i.e. <code>malloc</code> returns either good or bad (= <code>NULL</code>).</li>
<li>assert and log: These are debugging techniques, and should not be used as report mechanisms to users / clients. Asserts just say "something happened, that I can not handle - I quit".</li>
</ul>

blocks|key|2512695|text|如果无法访问用于生成/读取错误报告的终端，则应使用日志记录。|type|unordered-list-item|depth|inlineStyleRanges|entityRanges|data|2512696|返回真/假应与错误代码相结合。示例:函数在成功时返回True，在错误时返回False，并使用适当的错误代码/描述设置变量(全局变量或参数)。|2512697|例外情况:在我看来，将它们与日志记录和从错误中优雅地恢复结合起来是很好的。如果这是不可能的，您也可以求助于错误代码，作为例外，然后不提供额外的好处。|2512698|assert()：正如其他人指出的那样，它是在发布版本上编译的，因此可以随意使用。|2512699|2c|unstyled|2512700|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|N|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|O|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|P|8|@]|9|@]|A|$]]|$1|H|3|I|5|J|7|Q|8|@]|9|@]|A|$]]|$1|K|3|-4|5|J|7|R|8|@]|9|@]|A|$]]]|L|$]]

<ul>
<li>logging should be used if you don't have access to a terminal for producing/reading error reports.</li>
<li>returning True/False should be combined with error codes. Example: A function returns True on success, False on error, and sets a variable (global or parameter, your choice) with an appropriate error code/description.</li>
<li>exceptions: in my opinion, it's good to combine them with logging and graceful recovery from errors. If this is not possible, you might as well resort to error codes, as exceptions then provide no additional benefits.</li>
<li>assert(): As others have pointed out it compiles away on release builds, so fire at will.</li>
</ul>

2c

blocks|key|2512726|text|你报告的设备有多可靠？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2512727|我之所以这么问，是因为对于一大类设备，没有连接，没有打开，没有电池，忙着做其他事情等等，这些都是相当正常的状态。|2512728|如果是这样的话，如果设备以某种方式不可用，我将倾向于返回状态代码(注意，而不是错误代码)。|2512729|另一方面，如果您认为这些设备是超级可靠的，并且它们没有响应，那么异常处理可能是可行的。|2512730|如果(x+!=+0)+{+goto+error_routine；}，作为“异常”的mutch实际上只是一种非常好的编码方式，这并不重要，但是，我个人更喜欢处理异常情况，而不是像end_of_file这样的常规事件。|2512731|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|O|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

How reliable are the devices you are reporting on?

I ask because for a large class of devices not connected, not switched on, out of batteries, busy doing something else etc. etc. are fairly normal states.

If this is the case I would favour returning a status code (note not an error code ) if the device is somehow unavailable. 

If on the other hand you consider these devices super reliable and it really is exceptional for them not to respond then exception handling may be the way to go.

It doesn't really matter that mutch as 'exceptions' are really just a fancy way to code 'if (x != 0) { goto error_routine; }, but, I personally prefer exception handling to deal with exceptional situations not routine events like end_of_file.

blocks|key|986849|text|与真/假和错误代码相比，异常有几个重要的优点：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|986850|异常不能被忽略。如果您的代码抛出异常，调用方必须捕获它以避免获得未处理的异常。|unordered-list-item|986851|异常可以在比直接调用者更高的级别处理。如果您使用错误代码，您可能最终会在应用程序的所有层都必须检查错误并将它们传递给调用方。|986852|断言用于表示代码中的先决条件等内容，并有望在开发过程中发现任何bug。但是，您不应该依赖发布代码中的断言，而且出于性能原因，通常从发布代码中删除断言。|986853|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|L|8|@]|9|@]|A|$]]|$1|E|3|F|5|D|7|M|8|@]|9|@]|A|$]]|$1|G|3|H|5|6|7|N|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|O|8|@]|9|@]|A|$]]]|J|$]]

Exceptions compared to true/false and error codes have several important advantages:

<ul>
<li>Exceptions cannot be ignored. If your code throws an exception the caller has to catch it to avoid getting an unhandled exception.</li>
<li>Exceptions can be handled at a higher level than the immediate caller. If you use error codes you may end up in situations where you at all layers of you application have to check for errors and pass them back to the caller.</li>
</ul>

Asserts are used to express stuff like preconditions in your code and will hopefully uncover any bugs during development. However, you should not rely on asserts in your release code, and for performance reasons asserts are normally removed from release code.

blocks|key|2512797|text|我将反其道而行之，同时建议错误代码和异常，但这只是因为您正在创建一个库。既然你说你在做一个库，我猜这个库将提供给那些你无法控制的人编写的代码。因此，使您的代码对不同的编译器甚至语言友好是一件好事。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2512798|因此，我将编写一个C%2B%2B异常库，并提供详细说明异常类的头文件。我还会编写一个C接口，为用户处理异常。现在，用户可以链接到合适的接口：|2512799|#ifdef+__cplusplus__
void+generate_report(const+std::string&+rep_number,+ostream&+output);

extern+"C"+
#endif
int+generate_report(const+char*+rep_number,+const+char*+outputfilename,
++++++++++++++++++++int*+error_code,+char*+error_text,+int+max_error_text_len);|code-block|syntax|javascript|2512800|C实现调用C%2B%2B实现：|2512801|extern+"C"+
int+generate_report(const+char*+rep_number,+const+char*+outputfilename,
++++++++++++++++++++int*+error_code,+char*+error_text,+int+max_error_text_len)
{
++++ofstream+os;
++++try+{
++++++++os.open(outputfilename,+IOS_WRITE);
++++++++generate_report(rep_number,+os);
++++++++os.close();
++++++++return+TRUE;
++++}+catch+(base_exception&+e)+{
++++++++os.close();
++++++++if+(error_code)+*error_code+=+e.error_code();
++++++++if+(error_text)+strncpy(error_text,+e.str(),+max_error_text_len);
++++++++return+FALSE;
++++}
}|2512802|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|P|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|Q|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|R|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|S|8|@]|9|@]|A|$G|H]]|$1|M|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|N|$]]

I'm going to go against the grain and suggest both error codes and exceptions, but only because you are making a library. Since you say you are making a library, I'm guessing that library will be made available to code written by people you have no control over. So, making your code friendly to different compilers and possibly even languages is a good thing. 

So I would code a C++ exception library and provide header files detailing your exception classes. I would also code a C interface that handles the exceptions for the user. Now the user can link against which ever interface is appropriate:

<pre><code>#ifdef __cplusplus__
void generate_report(const std::string&amp; rep_number, ostream&amp; output);

extern "C" 
#endif
int generate_report(const char* rep_number, const char* outputfilename,
 int* error_code, char* error_text, int max_error_text_len);
</code></pre>

The C implementation calls the C++ implementation:

<pre><code>extern "C" 
int generate_report(const char* rep_number, const char* outputfilename,
 int* error_code, char* error_text, int max_error_text_len)
{
 ofstream os;
 try {
 os.open(outputfilename, IOS_WRITE);
 generate_report(rep_number, os);
 os.close();
 return TRUE;
 } catch (base_exception&amp; e) {
 os.close();
 if (error_code) *error_code = e.error_code();
 if (error_text) strncpy(error_text, e.str(), max_error_text_len);
 return FALSE;
 }
}
</code></pre>

I'm working on a library that generates reports of devices. The <code>generate_report (const std::string&amp; no)</code> member function can fail due to various reasons:

<ol>
<li>invalid report no.</li>
<li>invalid state (the <code>report_generator</code> is a FSM)</li>
<li>no device is active</li>
<li>error during report generation</li>
</ol>

Which error-handling mechanism is best for these errors?

<ul>
<li>just return <code>true</code> or <code>false</code></li>
<li>return error code</li>
<li>assert and log</li>
<li>throw exception(s)</li>
<li>any combination of the above</li>
</ul>

Some context information: the normal workflow is as following. The user activates a devices, chooses a report from a list and clicks on "generate".

EDIT: Thanks for the replies so far! For me it's clear now when to use asserts and when to do error-handling. As for error-handling, error codes and exceptions both have pros and cons. I think I go for exceptions (and create four classes for the above errors), but I'm not yet really convinced. I always thought of exceptions of 'unexpected situations'. An invalid report no isn't really unexpected. Any advice? :)

Exception vs. error-code vs. assert

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我正在开发一个库来生成设备的报告。由于各种原因，generate_report (const std::string& no)成员函数可能会失败：无效报告编号。无效状态( report_generator是FSM)没有设备处于活动状态。报表生成过程中的错误哪种错误处理机制最适合这些错误？只需返回true或false返回...

问异常与错误代码与断言
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问异常与错误代码与断言EN