Re: Exception Misconceptions
On Dec 22, 10:53 pm, ta...@mongo.net (tanix) wrote:
In article
<fc93ba82-f199-40b3-a7fd-71c24c7d2...@u7g2000yqm.googlegroups.com>,
James Kanze <james.ka...@gmail.com> wrote:
On Dec 22, 12:48 am, ta...@mongo.net (tanix) wrote:
In article
<a65d3221-02ca-4a18-907f-9027cce07...@c34g2000yqn.googlegroups.com>, James
Kanze <james.ka...@gmail.com> wrote:
[...]
The rate of coding is orders of magnitude higher nowadays
and complexities also.
Actually, I think in a lot of cases, the reverse is true. The
applications I see today are generally a lot simpler than those
of yesterday. For one thing, there's true runtime support for a
lot more functionality, so you don't have to implement it in the
application. And there are a lot of applications doing very
simple things---computers are cheap enough that you don't have
a complex operation to justify using one.
But both now and in previous times, there is a large interval
between the extremes. It wouldn't surprise me if the most
complex applications today were more complex than in previous
times. The least complex are certainly less complex. About all
I'd say is that the average application is less complex than
previously.
If you tell me I have to write my code WITHOUT exeptions, I
won't take your job offer. Sorry.
It would depend on the context. If they had a good reason for
not using exceptions, then OK. Otherwise, no.
Well, I would simply feel uncomfortable doing ANY job,
unless it is a kernel mode driver, where rules of the game
are quite different.
Kernel mode drivers were one of the cases I was thinking about.
I've also written for embedded processors with only 2 KB of ROM,
and 64 bytes of RAM. That was a long time agom but I'm sure
that there are still embedded processors with very limited
resources (many of which probably don't even have a C++
compiler---just C).
For an application on a general purpose machine, I'd have
serious doubts about a company which used C, or banned
exceptions in C++. But there's a lot more out there than just
general purpose machines.
[...]
Once you decide to go with return codes, that's it.
You have to test EVERY SINGLE return code.
That is definitely true. (Provided the "return code" returns
something useful or important. I wouldn't normally bother with
checking the return code of printf, for example, because it's
really meaningless.)
You can not make ANY assumptions.
If I EVER find something that does not need to return the
return code, because, for example, I solved it differently,
I immediately rewrite the called routine so it does not
return any return codes, just for the purity of code's sake.
The possible problem here is virtual functions: if one of the
derived classes can fail, all of the derived classes need a
return value (or to be able to throw an exception, or whatever).
[...]
But I am just curious: what is the essense of argument
that the exception processing, under non exception conditions,
can possibly incure a significant enough overhead to even
bother about it?
That it once did, for some primorial compiler? I don't know,
otherwise. It's certainly false today.
Is it a memory allocation/deallocation issue?
Sorry to mentioni Java again, but since I started working with
Java as my primary language, I just do not recall a single
case where exceptions were inefficient.
Exceptions are easier to make efficient when you don't have
value semantics, and objects with non-trivial destructors. It's
also easier to write incorrect code in such cases---as I said
elsewhere, one of the most common errors in Java is a missing
finally block. Still, except for some very early, experimental
implementations, I don't know of a case where an exception that
wasn't thrown has caused performance problems in C++ either.
It's also possible to misuse exceptions, so that they get thrown
in the normal logic of program execution. I've heard of such
cases (although I've never seen them in code I've had to deal
with).
Still, any argument against exceptions based on performance is
simply FUD, at least IMHO.
when there are things that have to be cleaned up, and the
author didn't think about exceptions.
Well, that comes as a skill. Sooner or later they will learn,
or loose their job. THEN they WILL learn for sure.
The problem is that they don't necessarily learn. Since the
problem only occurs in "exceptional" cases, and a lot of people
neglect testing those.
It's interesting to note that in the Java runtime, when opening
a file fails, they run garbage collection and try again.
Because a lot of people forget a finally block when they've
opened a file, and in case of an exception, never close it.
(Whereas in my code, most of the time, if it's an output file,
and there is an exception, I not only close the file, but delete
it. So there's no inconsistent file lying around after the
program has run.)
[...]
Do you have MORE logic in your program if you use return codes?
Or LESS?
You have the same amount of logic. Or else there's an error
somewhere. The only difference is that with exceptions, some of
the logic isn't visible, and doesn't have to be manually
written. (It does still have to be considered when analysing
program correctness.)
Don't confuse logic with lines of code.
--
James Kanze