|
I used to use the "reserved return value" method, but I've converted to using HRESULTs for the retval, and any additional output is returned through reference parameters. Using a consistent retval system is actually easier, because the caller doesn't have to think "now does this function return 0 or -1 (or NULL or INVALID_HANDLE_VALUE) on error?" when using my functions. Every retval can be tested with SUCCEEDED/FAILED.
|
|
|
|
|
Nothin' i hate worse than cluttering up my beautiful code with all sorts of error checking. 
But yeah, unless there's a way of recovering from an error, i prefer to throw an exception and let the UI deal with reporting the problem.
----
It appears that everybody is under the impression that I approve of the documentation. You probably also blame Ken Burns for supporting slavery.
--Raymond Chen on MSDN
|
|
|
|
|
|
Many years ago I found a desent recursive parser (C code) that used longjmp(). The first thing I did was eliminate the need for it by using return values, because I considered that a poor solution to the problem and have never used longjmp() in any of my code.
Note: Exceptions where not an option, at the time.
INTP
"Program testing can be used to show the presence of bugs, but never to show their absence."Edsger Dijkstra
|
|
|
|
|
With C++ you do not have to. I learned this trick it long time ago
#define HR(f) {HRESULT hr = f; if( hr < 0 ) return hr;}
then any call of any function will be
HR(CreateFile(..));
That will automaticly unwind your stack like exception does.
|
|
|
|
|
At some point, you still need to manually check the return code and interpret it. Call GetLastError(), throw together some context based on what you needed the file for or where you were trying to create it.
Personally, i'd just as soon keep all WinAPI plumbing in one spot, extract as much context as possible, and then pass it on. Whether that involves throwing an exception, setting a flag, or a Dunn-esque combo of return values and reference parameters depends on the needs of the caller.
----
It appears that everybody is under the impression that I approve of the documentation. You probably also blame Ken Burns for supporting slavery.
--Raymond Chen on MSDN
|
|
|
|
|
Michael Dunn wrote: Exceptions are evil
 Now, that's a bit too strong, I think. Exceptions are useful in exceptional (pun intended) situations. The main problems I see with them are:
1) Using exceptions for normal program flow - for instance to avoid using goto when breaking out of a nested loop.
2) Using exceptions without applying exception safety coding principles, which leads to all sorts of resource leaks and objects in undefined state.
In general it is a very good idea to read Sutter's Exceptional C++[^] (even for programmers who use other languages) to learn how to use exceptions in a safe and productive manner.
|
|
|
|
|
Generally and especially for critical errors I prefer logging a clear-cut message to the event log in addition to returning a predefined error code.
"Silence will create respect and dignity; justice and fair play will bring more friends;
benevolence and charity will enhance prestige and position; courtesy will draw benevolence;
service of mankind will secure leadership and good words will overcome powerful enemies"
Ali (Peace be upon him)
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
