Re: Exception Misconceptions: Exceptions are for unrecoverable
errors.
On Dec 23, 12:45 pm, ta...@mongo.net (tanix) wrote:
In article <hgskgk$kc...@news.albasani.net>, Vladimir Jovic
<vladasp...@gmail.com> wrote:
James Kanze wrote:
On Dec 22, 4:55 pm, Kaz Kylheku <kkylh...@gmail.com> wrote:
On 2009-12-22, Vladimir Jovic <vladasp...@gmail.com> wrote:
Stefan Ram wrote:
[snip]
More elegantly? Actually, for correct and secure C++
code, all functions need to be written to be =BBexception
safe=AB, but only a minority of C++ programmers does so or
even is aware of it.
Why?
The above is false. Exception-safe code is needed to write
code that avoids resource leaks in the face of an exception.
It's need to write code that is correct in the face of an
exception. What "correct" means depends on the application
specifications. (On the other hand, what he wrote is false
in so far that if the function calls no other function, or
only calls functions guaranteed not to throw, it doesn't
have to be exception safe.)
Ok, I forgot about that. Thank you.
But how many people are adding what exception can a method
throw in it's declaration? (forgot how it is called. Is it
exception declaration?) All normal coding styles are telling
that is causing more trouble then it helps.
First, many people do use "throw()" when a function cannot
throw. But that's beside the point: when you're writing code,
you do have to know whether the function can throw or not;
whether this information is provided by a language construct or
the documentation is really irrelevant.
For instance:
{
char *p = new char[256];
f();
}
If f throws an exception, this statement block is
abandoned, and the allocated memory is leaked.
Or not. If the application is using garbage collection,
it's not leaked. If the application immediately terminates
(and is in a hosted environment), it's not leaked.
Not many people are using GC :P
I recall seeing some articles on gc issue in C++ a while back
on this very group. Do not remember what it was.
But what can I say out of my own experience with Java is this:
A well written GC is such a help, that I can not even see the
argument of not implementing it to this day.
I agree, but you can't loose sight of the fact that Java and C++
are two different languages. Garbage collection is nice in C++:
it definitely makes it easier to write correct code in a lot of
cases, and it is essential for safety (no dangling pointers) in
others. But it isn't nearly as essential in C++ as in Java,
because C++ supports value semantics. Which mean that you don't
use nearly as many dynamically allocated objects, and most of
the ones you do use have deterministic lifetimes anyway. (Of
course, the safety issue still stands.)
I bet you can not even imagine how much times was wasted to
date by the programmers to deal with this totally stoopid
issues related to memory deallocation. Probably at least 30%
of total time spend on developing the C++ code.
Generally less than 10% of the time. But given the cost of
competent engineers, even 10% is worth it.
C++ would probably be benefited tremendously if it adopted
some of the central Java concept, such as GC, threads and GUI.
Except that would require an equivalent of a virtual machine
underneath.
Not at all. I've used garbage collection in C++, and I've used
C++ in multithreaded programs. And a lot of people have written
GUI's in C++. All without a virtual machine.
All would be nice additions, IMHO, although for various
reasons, I don't think a standard GUI would be possible today.
--
James Kanze