blocks|key|1449990|text|我个人更喜欢前一种方法(返回一个错误指示符)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1449991|必要时，返回结果应仅指示发生了错误，并使用另一个函数来找出确切的错误。|1449992|在您的getSize()示例中，我认为大小必须始终为零或正数，因此返回负结果可能表示出现错误，这与UNIX系统调用非常相似。|1449993|我想不出我使用过的任何库都支持后一种方法，将error对象作为指针传入。stdio等都带有返回值。|offset|length|style|CODE|1449994|entityMap^0|0|0|0|10|5|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|P|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|Q|8|@$H|R|I|S|J|K]]|9|@]|A|$]]|$1|L|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|M|$]]

I personally prefer the former approach (returning an error indicator).

Where necessary the return result should just indicate that an error occurred, with another function being used to find out the exact error.

In your getSize() example I'd consider that sizes must always be zero or positive, so returning a negative result can indicate an error, much like UNIX system calls do.

I can't think of any library that I've used that goes for the latter approach with an error object passed in as a pointer. <code>stdio</code>, etc all go with a return value.

blocks|key|1665196|text|我当然更喜欢第一种解决方案：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1665197|int+size;
if(getObjectSize(h,+&size)+!=+MYAPI_SUCCESS)+{
++//+Error+handling
}|code-block|syntax|javascript|1665198|我会稍微修改一下，如下所示：|1665199|int+size;
MYAPIError+rc;

rc+=+getObjectSize(h,+&size)
if+(+rc+!=+MYAPI_SUCCESS)+{
++//+Error+handling
}|1665200|另外，我永远不会把合法的返回值和错误混在一起，即使目前函数的作用域允许你这样做，你永远不会知道将来函数实现会走哪条路。|1665201|如果我们已经讨论了错误处理，我建议使用goto+Error;作为错误处理代码，除非可以调用某个undo函数来正确处理错误。|offset|length|style|CODE|1665202|entityMap^0|0|0|0|0|0|J|B|1B|4|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|V|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|W|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|X|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|Y|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|Z|8|@$O|10|P|11|Q|R]|$O|12|P|13|Q|R]]|9|@]|A|$]]|$1|S|3|-4|5|6|7|14|8|@]|9|@]|A|$]]]|T|$]]

I definitely prefer the first solution :

<pre><code>int size;
if(getObjectSize(h, &amp;size) != MYAPI_SUCCESS) {
 // Error handling
}
</code></pre>

i would slightly modify it, to: 

<pre><code>int size;
MYAPIError rc;

rc = getObjectSize(h, &amp;size)
if ( rc != MYAPI_SUCCESS) {
 // Error handling
}
</code></pre>

In additional i will never mix legitimate return value with error even if currently the scope of function allowing you to do so, you never know which way function implementation will go in the future. 

And if we already talking about error handling i would suggest <code>goto Error;</code> as error handling code, unless some <code>undo</code> function can be called to handle error handling correctly.

blocks|key|1450218|text|编辑:如果您只需要访问最后一个错误，并且您不在多线程环境中工作。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1450219|你可以只返回true/false+(如果你在C中工作并且不支持bool变量，也可以返回某种类型的#define+)，并且有一个全局错误缓冲区来保存最后一个错误：|1450220|int+getObjectSize(MYAPIHandle+h,+int*+returnedSize);
MYAPI_ERROR+LastError;
MYAPI_ERROR*+getLastError()+{return+LastError;};
#define+FUNC_SUCCESS+1
#define+FUNC_FAIL+0

if(getObjectSize(h,+&size)+!=+FUNC_SUCCESS+)+{
++++MYAPI_ERROR*+error+=+getLastError();
++++//+error+handling
}|code-block|syntax|javascript|1450221|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|L|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|M|8|@]|9|@]|A|$G|H]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

EDIT:If you need access only to the last error, and you don't work in multithreaded environment.

You can return only true/false (or some kind of #define if you work in C and don't support bool variables), and have a global Error buffer that will hold the last error:

<pre><code>int getObjectSize(MYAPIHandle h, int* returnedSize);
MYAPI_ERROR LastError;
MYAPI_ERROR* getLastError() {return LastError;};
#define FUNC_SUCCESS 1
#define FUNC_FAIL 0

if(getObjectSize(h, &amp;size) != FUNC_SUCCESS ) {
 MYAPI_ERROR* error = getLastError();
 // error handling
}
</code></pre>

blocks|key|1665378|text|第二种方法允许编译器生成更优化的代码，因为当变量的地址传递给函数时，编译器在后续调用其他函数时不能将其值保留在寄存器中。完成代码通常只使用一次，就在调用之后，而从调用返回的“真实”数据可能会更频繁地使用|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1665379|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|$]]

Second approach lets the compiler produce more optimized code, because when address of a variable is passed to a function, the compiler cannot keep its value in register(s) during subsequent calls to other functions. The completion code usually is used only once, just after the call, whereas "real" data returned from the call may be used more often

blocks|key|1450391|text|我最近也在思考这个问题，并使用纯本地返回值编写了some+macros+for+C+that+simulate+try-catch-finally+semantics。希望你会发现它是有用的。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1450392|entityMap|0|LINK|mutability|MUTABLE|url|http://higherlogics.blogspot.com/2010/09/high-level-constructs-for-low-level-c.html^0|O|1N|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 was pondering this issue recently as well, and wrote up <a href="http://higherlogics.blogspot.com/2010/09/high-level-constructs-for-low-level-c.html" rel="noreferrer">some macros for C that simulate try-catch-finally semantics</a> using purely local return values. Hope you find it useful.

blocks|key|1665542|text|当我编写程序时，在初始化期间，我通常会关闭一个用于错误处理的线程，并初始化一个特殊的错误结构，包括一个锁。然后，当我检测到错误时，通过返回值，我将来自异常的信息输入到结构中，并向异常处理线程发送SIGIO，然后查看是否无法继续执行。如果不能，我会向异常线程发送一个SIGURG，它会优雅地停止程序。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1665543|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|$]]

When I write programs, during initialization, I usually spin off a thread for error handling, and initialize a special structure for errors, including a lock. Then, when I detect an error, through return values, I enter in the info from the exception into the structure and send a SIGIO to the exception handling thread, then see if I can't continue execution. If I can't, I send a SIGURG to the exception thread, which stops the program gracefully.

blocks|key|1665630|text|这是一种我认为很有趣的方法，但需要一些纪律。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1665631|这假设句柄类型的变量是在其上操作所有API函数的实例。|1665632|其思想是，句柄后面的结构将先前的错误存储为具有必要数据(代码、消息...)的结构，并为用户提供一个函数，该函数返回指向此错误对象的指针。每个操作都会更新指向的对象，这样用户甚至不需要调用函数就可以检查其状态。与errno模式相反，错误代码不是全局的，这使得该方法是线程安全的，只要正确使用每个句柄即可。|1665633|示例：|1665634|MyHandle+*+h+=+MyApiCreateHandle();

/*+first+call+checks+for+pointer+nullity,+since+we+cannot+retrieve+error+code
+++on+a+NULL+pointer+*/
if+(h+==+NULL)
+++++return+0;+

/*+from+here+h+is+a+valid+handle+*/

/*+get+a+pointer+to+the+error+struct+that+will+be+updated+with+each+call+*/
MyApiError+*+err+=+MyApiGetError(h);

MyApiFileDescriptor+*+fd+=+MyApiOpenFile("/path/to/file.ext");

/*+we+want+to+know+what+can+go+wrong+*/
if+(err->code+!=+MyApi_ERROR_OK)+{
++++fprintf(stderr,+"(%25d)+%25s\n",+err->code,+err->message);
++++MyApiDestroy(h);
++++return+0;
}

MyApiRecord+record;

/*+here+the+API+could+refuse+to+execute+the+operation+if+the+previous+one
+++yielded+an+error,+and+eventually+close+the+file+descriptor+itself+if
+++the+error+is+not+recoverable+*/
MyApiReadFileRecord(h,+&record,+sizeof(record));

/*+we+want+to+know+what+can+go+wrong,+here+using+a+macro+checking+for+failure+*/
if+(MyApi_FAILED(err))+{
++++fprintf(stderr,+"(%25d)+%25s\n",+err->code,+err->message);
++++MyApiDestroy(h);
++++return+0;
}|code-block|syntax|javascript|1665635|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|6|7|Q|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|R|8|@]|9|@]|A|$]]|$1|H|3|I|5|J|7|S|8|@]|9|@]|A|$K|L]]|$1|M|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|N|$]]

Here is an approach which I think is interesting, while requiring some discipline.
This assumes a handle-type variable is the instance on which operate all API functions.
The idea is that the struct behind the handle stores the previous error as a struct with necessary data (code, message...), and the user is provided with a function that returns a pointer to this error object. Each operation will update the pointed object so the user can check its status without even calling functions. As opposed to the errno pattern, the error code is not global, which make the approach thread-safe, as long as each handle is properly used.
Example:
<pre><code>MyHandle * h = MyApiCreateHandle();

/* first call checks for pointer nullity, since we cannot retrieve error code
 on a NULL pointer */
if (h == NULL)
 return 0; 

/* from here h is a valid handle */

/* get a pointer to the error struct that will be updated with each call */
MyApiError * err = MyApiGetError(h);

MyApiFileDescriptor * fd = MyApiOpenFile(&quot;/path/to/file.ext&quot;);

/* we want to know what can go wrong */
if (err-&gt;code != MyApi_ERROR_OK) {
 fprintf(stderr, &quot;(%d) %s\n&quot;, err-&gt;code, err-&gt;message);
 MyApiDestroy(h);
 return 0;
}

MyApiRecord record;

/* here the API could refuse to execute the operation if the previous one
 yielded an error, and eventually close the file descriptor itself if
 the error is not recoverable */
MyApiReadFileRecord(h, &amp;record, sizeof(record));

/* we want to know what can go wrong, here using a macro checking for failure */
if (MyApi_FAILED(err)) {
 fprintf(stderr, &quot;(%d) %s\n&quot;, err-&gt;code, err-&gt;message);
 MyApiDestroy(h);
 return 0;
}
</code></pre>

blocks|key|1665717|text|除了其他很好的答案之外，我建议您尝试将错误标志和错误代码分开，以便在每次调用时保留一行，即：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1665718|if(+!doit(a,+b,+c,+&errcode)+)
{+++(*+handle+*)
++++(*+thine++*)
++++(*+error++*)
}|code-block|syntax|javascript|1665719|当你有很多错误检查的时候，这个小小的简化真的很有帮助。|1665720|entityMap^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|$E|F]]|$1|G|3|H|5|6|7|M|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

In addition the other great answers, I suggest that you try to separate the error flag and the error code in order to save one line on each call, i.e.:

<pre><code>if( !doit(a, b, c, &amp;errcode) )
{ (* handle *)
 (* thine *)
 (* error *)
}
</code></pre>

When you have lots of error-checking, this little simplification really helps.

What do you consider "best practice" when it comes to error handling errors in a consistent way in a C library.

There are two ways I've been thinking of:

Always return error code. A typical function would look like this:

<pre><code>MYAPI_ERROR getObjectSize(MYAPIHandle h, int* returnedSize);
</code></pre>

The always provide an error pointer approach:

<pre><code>int getObjectSize(MYAPIHandle h, MYAPI_ERROR* returnedError);
</code></pre>

When using the first approach it's possible to write code like this where the error handling check is directly placed on the function call:

<pre><code>int size;
if(getObjectSize(h, &amp;size) != MYAPI_SUCCESS) {
 // Error handling
}
</code></pre>

Which looks better than the error handling code here. 

<pre><code>MYAPIError error;
int size;
size = getObjectSize(h, &amp;error);
if(error != MYAPI_SUCCESS) {
 // Error handling
}
</code></pre>

However, I think using the return value for returning data makes the code more readable, It's obvious that something was written to the size variable in the second example.

Do you have any ideas on why I should prefer any of those approaches or perhaps mix them or use something else? I'm not a fan of global error states since it tends to make multi threaded use of the library way more painful.

EDIT:
C++ specific ideas on this would also be interesting to hear about as long as they are not involving exceptions since it's not an option for me at the moment...

Error handling in C code

编译器

当涉及到在C库中以一致的方式处理错误时，您认为什么是“最佳实践”？我一直在想两种方式：始终返回错误代码。典型的函数如下所示：MYAPI_ERROR getObjectSize(MYAPIHandle h, int* returnedSize);始终提供错误指针方法：int getObjectSize(MYAPIHand...

问C代码中的错误处理
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问C代码中的错误处理EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问C代码中的错误处理
EN