|
peterchen wrote: The main problem with C++ is that it's not easy to "fall back to a stable point", if your heap is corrupted, you are done.
Well, that's probably true of most languages / platforms. C++ just makes it a bit easier to corrupt your heap...
peterchen wrote: and that local handliing is very verbose (but the Likely<t> stuff by Andrei/Petru look tempting for that)
Agreed.
----
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
|
|
|
|
|
In hasty response, sales of exception-safe code before and after Sutter-era journalism did nothing to prove such code is:
a) around aplenty
b) performs better
c) is more maintainable
d) appropriate for component-based development in C++
While I am slightly worried to see ATL roots here acknowledging the fact exceptions can produce more readable and maintainable code, I must agree with it if you look at that fragment (readable, maintainable), word by word. But not any further than that.
All I can do is give my short and uninformed story:
For one, a lot of effort went into exception-less STL and platforms that had no compiler or runtime support. Same goes for ATL and WTL I guess.
The following one is not on checked access, but on checked concepts, one of them being iterators are priceless as they can report subtle errors no exception or errorcode-based code can resolve - logic bugs.
Writing service or system software was done in C (until Vista I guess), and huge body of work went into it. People still argue on specification lists and what if any of exception-related information should be in the metadata.
Lastly, no exception hype or book or next modern mechanism can protect against exceptional circumstances of OS, security, network or any other type of 'integrity' failure. Attempting to use C++ as a tool for transactional programming (be that replication work before moving on to compiler team or not), without expecting C like and MTS like interfaces is, in my mind, a good waste of time.
If you are attempting to save your application state, than you might as well do a differential backup, continuous backup, pre-allocate storage, and do whatever you were going to do with exceptions because they will not help you much more once you hit the 'exceptional circumstances'.
Heard of : 'Program encountered an error. Please save your work', only to see the Save operation initiate a crash of the system?
Exceptions do not improve availability either, and I could argue they disable plenty of optimisations new (re:copy of old) hardware architectures are providing.
Examples:
MS Word crashes with or without exceptions.
IE too.
SQL Server reports rejection on overload, do you as a client bomb out too?
Your OS becomes unresponsive any time it deals with any good file manipulation, do you bomb out?
And who do you bomb out to?
Simply the next 'manager' that is very likely to bomb out, and so the story goes all the way down to halt or blue screen (or your system requires administration anyway, like restart).
That is how most software works, and exceptions are just an implementation detail that makes a lot of overhead in service-based or OS software.
Having criticised exceptions for time I have for the discussion, I can see a good use to them if you are looking out for integrity hype that exceptions never achieved. The best possible use I can see to them is in deep 'inner scope' of a function, making programming/interfacing to 3rd party components clean and lazy (as in simplified error checks).
The fact is if you do not understand a large number of conditions or values you might be hit with, or have provisioned for them to a 'good enough' extent, you are more likely to have an event tracing use rather than an exception use in your code (see the trend in all software overwhelming your Event Log with information).
Using a catch all clause can help against further corruption sure, but if you know those values why not record them or better handle them so your system is in maintenance mode for you to see, rather than having it obscured in a complex 'unwinding interaction'.
Besides, you know it all ducks when those slow CLR dialogs appear, especially on floating point arithmetic, bad XML, and file manipulation.
And, quite frankly, ‘The Power Of None’ seems like another attempt at template masturbation while another X systems and runtimes are on your path, on a daily basis, on a another piece of unreadable Martian writing.
Less code is better, but less code is ‘other’ services too, not just exceptions.
Example: what NX bit did for C code.
Sincerely,
6
-- modified at 19:19 Tuesday 17th April, 2007
|
|
|
|
|
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
