Re: Exception Misconceptions
In article <fc93ba82-f199-40b3-a7fd-71c24c7d2b07@u7g2000yqm.googlegroups.com>, James Kanze <james.kanze@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:
[...]
Well, THEORETICALLY, it can happen even without using
exceptions. In reality, it is just a joke.
It's no joke. It's an everyday reality. Most of the phone
switches and transmission systems go back to a time before
exceptions, and they work. Year in, year out, without
interruption.
Yep. No argument there. Except those apps are infantile
by todays standards.
They were a good deal more complex than anything I've seen
written recently.
Well, I did not mean it to be an insult. Trust me.
But just to put things in perspective.
The rate of coding is orders of magnitude higher nowadays
and complexities also.
And I will never agree with you on exceptions,
even though it is not a matter of principle for me.
I just saw WAY too many benefits of it and WAY too many cases
where they made things MUCH simpliers, much more predictable,
and much more structured.
My "granularity" argument still stands.
You don't need to get lost in the forest by dealing with
never ending collections of trees in front of you.
I can call it a "granularity benefit", whether it makes sense
for you or not.
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.
But I would feel like I am working in "unclean" environment,
and I would intuitively feel horrified with ALL sorts of
crappy code and orders of magnitude more load on my brain
just because I have to deal with every single return code
on every single non significant level.
Once you decide to go with return codes, that's it.
You have to test EVERY SINGLE return code.
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.
I do not know why some claim the exception mechanism is so
inefficient even in cases where there are not exceptions, but
that is another matter.
Memories of early compilers?
Well, I am probably not seeing the picture YOU are seeing.
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?
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.
I do keep a constant watch for performance issues, because those
are VERY critical in my case because most of the "jobs" I run
run for hours, if not days. Just saving a couple of hours of
job processing time, it helps quite a bit.
I can only guess that if you want to get TOO sophosticated and
assure that you can unwind the stack even considering the on
heap allocations and things like that, and, as a result, have
to save all sorts of things prepairing to run the exceptions
bound code, may be.
I'm not sure which side of the issue you're looking at above.
From the language point of view, it's clear what has to be done,
and techniques exist (and are used in most compilers) which have
0 overhead (or almost) in the case when an exception isn't
thrown.
That's IT then. That is ALL I want to hear.
In my case, once exception is THROWN, then fine, take ALL the
time you need and use ANY resources you need to make it as
informative as you can manage, if it is a major operation
and user might not know the state of the whole thing and
have to waste hours if not days to recover.
All the other lil exceptions, such as string to number conversion,
simply become a part of the flow. The exception handling overhead
is totally insignificant. Because, first of all, those things
happen EXTERMELY rarely, and if they do, an you have to deliver
a defalut value because your conversion failed, which is slow
enough as it, then it is a totally non issuse. Nothing even worth
mentioning.
From the programmer's point of view: if you have to
write any special handling in C++, you're not writing idiomatic
C++. But one of the more frequent errors I've seen in Java is a
missing finally block,
Well, that is true. I do agre on this one.
I do try to keep an eye on these kinds of things for vast majority
of cases and never let it slide.
Actually, I use the "finally" quite extensively,
because I need to keep a good handle on my memory allocations/
deallocations issues. Cause I may end up holding hundreds of
gigs of memory unnecessarily for unnecessarily long periods of
time.
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.
Who knows?
For one thing, without exceptions your code becomes a huge
pile of spegetti code and I know what I am talking about.
Apparently not,
Apparently yes.
I've worked on some very large projects without exceptions, and
the code was not at all a pile of spaghetti. It was, in fact, a
lot cleaner than a lot of code I see today, with exceptions.
Well, to tell you the truth I am not prepaired to argue this
point right now. It seems to me to be self evident.
Just a simple fact:
Do you have MORE logic in your program if you use return codes?
Or LESS?
How much MORE logic do you have?
Well, I estimate AT LEAST 30% of your code, if not 300% for the
sake of artument, has to handle that code. Otherwise you are
just a fool that created codes that are useless since you are
not using them.
I could probably spend a few minutes of my time to give you
a pretty typical piece of code with exceptions and the same
exact code without exceptions.
It'll look like night and day in terms of code clarity
and the size of that code.
But I am getting too much wrapped up into this "exceptions"
or "no exceptions" trip. I AM wasting too much time and
energy on it.
Why do I even need to try to prove anything to someone,
who thinks otherwise?
Stoopid of me indeed.
I just wrote too much code to make such a statement. It is
simply inevitable.
So inevitable that it doesn't take place.
:--}
Yep, I know your style by now.
Enjoy.
Cya.
I'm tempted to say the opposite. Exceptions are just another
tool. A very convenient and effective one in specific cases,
but still just a tool. If you can't write clean code without
them, then you can't write it with them. Like any tool, they
don't change your native ability; all they do is make some
things (that you could do anyway) easier and less effort.
because I've worked on very large code bases,
without exceptions,
Again, this is a general purpose statement that does not
prove anything.
It's the exception that disproves your claim. (Obviously, I
can't post the code here, because it was propriatory. And
because it was several million lines of code, which would make
for a pretty large posting.)
Either you do test of your return codes, or you don't.
If you decide to do, and your logic runs to check all the
codes, then your code size and the amount of spagetti is
probably at least 30% bigger.
That's only if you don't know how to write code.
With exceptions, you do not check ANY return code
more or less. Clear to a 5 year old what it means.
Yes. That you're not handling a lot of errors the way they
should be. There aren't that many errors which warrent
exceptions. Most should be processed immediately.
[...]
Sorry. I can not agree with you on this one.
I think you are somehow predisposed AGAINST exceptions.
Not at all.
Yes you are. I have seen some of your posts.
Then you know that I'm not against exceptions. That I use them
when appropriate.
[...]
and we still managed to write robust and
maintainable applications.
Well. I am not saying it is not possible in PRINCIPLE.
I am saying it is a royal pain on the neck.
It's more effort, that's for sure. But there are a lot of
other things with even more impact.
In fact, I will make this claim:
If you do NOT use exceptions, you are just a lazy bum.
Or you're working in a context where they aren't appropriate,
for some reason. (On a really small embedded system, for
example.) But I do use exceptions. I also use return codes,
assertion failure, and deferred error checking (as in iostream
or IEEE floating point). I have more than one tool in my tool
kit, and I use which ever one is most effective for the job at
hand.
--
Programmer's Goldmine collections:
http://preciseinfo.org
Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
organized by major topics of language, tools, methods, techniques.