W
White Wolf
dragan said:
And he has demonstrated an unprecedented number of misconceptions and
very little knowledge of what he is talking about.
And he has demonstrated an unprecedented number of misconceptions and
very little knowledge of what he is talking about.
W
White Wolf
dragan said:
Effective C++ 3rd edition, very few items are about exceptions and there
is all you need to know.
D
dragan
So what? Code outside of the mainline during exceptional conditions does not
have to be fast.
have to be fast.
D
dragan
White said:
Unprecendented eh?
He seems to know MUCH about low level implementation details. So if he knows
"very little", I must know only VERY VERY little.
(P.S. You missed the most important part of my other post that you "tore
up").
W
White Wolf
Paavo said:
Notoriously slow is a pretty vague statement. Exceptions do not slower
the speed of the code unless they are thrown. So your choices are: slow
your happy code (that runs a billion times) by inserting hundreds of if
statements into it to propagate return codes up the call stack to the
handler, or make returning 1000 times slower 3 times a day... It is a
no brainer to me.
But in case of Google, there may be another reason. Exceptions are not
for reporting results of operations, they are to report errors that
cannot be handled where they are detected. Since Google services live
in a cloud, it may be easier to kill the misbehaving program (that could
not open a file) and restart the whole machine then trying to handle the
error. There will be a few million more computer who can do the thing.
So the real reason could be that Google has a lot easier way to deal
with misbehavior that normally would be handled by an exception. Move
the task to another process, machine, city... and kill the one that went
bananas.
But, this is still just a guess.
D
dragan
White said:
You are arguing "either or", "one extreme or the other".
W
White Wolf
dragan said:
No need for attitude. Yes. Unprecedented amounts of false assumptions.
He seems to know MUCH about low level implementation details. So if he knows
"very little", I must know only VERY VERY little.
He seems. He write about his assumptions and misconceptions as if they
were fact. Very confident. very misleading. And yet, when you take a
closer look, you see that he does not even know what a compile time
constant is, and that upcasting+member access in multiple inheritance is
practically the same speed as in single inheritance.
He has a lot of wild guesses and presents them as fact.
I have found no evidence that he *knows* much about any low level
details. I have seen he has *opinions* about them, and presents them as
facts.
I probably shall have have no comments on your assessment of your own
knowledge of what you call low level details, but if you buy into the
wild guesses in that article without feeling uneasy, well, you are
probably right.
I did not tear up anything. I have follow the USENET netiquette and
reply to those parts where I have something to say. And I am sorry, I
cannot identify what is "my other post". If you want to talk about that
other post, please reply to the other reply.
Then I will have a chance to understand why do you feel that I was unfair.
D
dragan
White said:
Ah, trying to turn the table huh. Well, you're well on your way to 5th grade
level of discussion.
You were exploiting and sensationalizing and you know it. Being caught in
the act, you try to play it down with the "try to turn the table" tactic.
What the child does not know is that the tactics are common knowledge. So
the child keeps believing that he/she is smarter than everyone else when in
reality the child is unknowingly showing his/her ignorance.
And you write: "Unprecendented amounts of false assumptions", as if it were
fact. To which I replied: "Unprecedented eh?".
And you skip to literary correction when "new operator" was used even though
from the context it is clear what was being discussed. So, not only no bonus
for you, but penalty.
And you don't know that quotation marks are to be used where you used
asterisks above or maybe you are conveniently ignoring what quotation marks
do within a context to the meaning of the quoted words so that you can go on
with your childish tactics.
Oh no, of course not. (He he).
I have follow the USENET netiquette and
reply to those parts where I have something to say. And I am sorry, I
cannot identify what is "my other post". If you want to talk about
that other post, please reply to the other reply.
have a chance to understand why do you feel that I was unfair.
I didn't say you were "unfair". The post you "tore up" is the one where I
had a list of 12 things. You missed the most important part. I hope you are
either 9 years old or have a wife, because you need help. :/
W
White Wolf
dragan said:
http://usenet4all.se/rfc1855.txt
"
- Use symbols for emphasis. That *is* what I meant. Use
underscores for underlining. _War and Peace_ is my favorite
book.
"
D
dragan
White said:
Oh, I gave you too much credit on that one then: I thought you were trying
to do something more than just emphasize those words. Nevermind on that one.
J
James Kanze
What is the perceived problem? And why is aborting (as a
default behavior) a bad solution? Violating an exception
specification is a contract violation, so aborting *is* about
the only appropriate default behavior. The question is: what
problem is solved by supporting contracts in which a function
is allowed to throw a limited set of exceptions (as opposed to
no exception).
They don't detect the error when it occurs. And they result in
stack unwinding occurring---something you definitely don't want
if the exception is a contract violation.
This example, yes. Changing it, however, would involve breaking
C compatibility. I was thinking of the common case:
S s(S(a));
, where a is an already existing variable. Regretfully, most
headers are full of this sort of thing, rather than e.g.:
extern S s(S(a));
(if they are declaring a function).
Again, in this simple case, you could drop the extra parentheses
in the function decaration, but banning an extra set of
encapsulating parentheses would complicate the grammar
excessively.
Thinking about it: one could probably get away with 1) dropping
the implicit conversion of the parameter type for functions, and
2) banning outermost parentheses. It's an idea, but you'd need
some volenteer to come up with the wording for point 2, since it
means redefining the grammar for type expressions in some way.
J
James Kanze
Just a linguistic nit, but formally, "unprecedented" means that
there is no precedent---no one has done it before. Given this
definition, I wouldn't call posting a web page on a subject you
know nothing about exactly "unprecedented"
.Not that that that changes anything with regards to your
argument.
W
White Wolf
James said:Just a linguistic nit, but formally, "unprecedented" means that
there is no precedent---no one has done it before. Given this
definition, I wouldn't call posting a web page on a subject you
know nothing about exactly "unprecedented"
Not that that that changes anything with regards to your
argument.
I was referring to an "unprecedented amount". I mean if we disregard
the known trolls. I do not regard the OP as a troll, so it made me very
sad to see so many bad assumptions.
D
dragan
James said:
I've watched these threads before and found that they go around and around.
The reason is because you all are jumping the gun seeking the "one and only"
thing instead of being patient and doing some research. Error handling is
application-specific. Without a well-defined problem, discussions get no
where toward solution and no one learns anything. James, you said, "aborting
is not necessarily bad". Well, of course not. It depends on the application.
It is but one of many avenues to take upon detecting (detection is a key
concept) that a potentially "disastrous" thing will occur unless processing
doesn't take a side road immediately. If you believe what I just said, and I
believe you do, then you see why I question those who consider C++
exceptions as an error management strategy. C++ exceptions are JUST a
mechanism. NOT a solution to the error management problem. Yet I am sure
that chatter and banter about the mechanisms rather than the problem will
continue. How to accellerate the learning is the question.
Maybe. (Read, I'm not sure 'bout that). I don't know what you mean. Did you
just elevate "function argument requirements" to "exception specification"?
If so, given the current "climate" and confusion with error handling, you'd
expect me to BELIEVE your "exception specification" as some kind of
authoritative thing? C'mon, let's get real. "Before", there was "a function
has, "a contract". Are you suggesting now that a function has "an exception
specification" all is good? C'mon, who uses those things in C++? That is so
yesterday. It failed. Didn't it?
No doubt you seek to write meaningless definitions for specifications? ;P
<-(combinatorial emoticon) (Should I patent it?).
Define "unexpected exception" please. I didn't know that C++ recognized such
a beast. I can't quote anything from the standard or the tomes, but in my
mind remains that exceptions in C++ are EXPECTED things. Am I wrong or are
you? One of us has to be.
To be real, detection is all about preventing "undefined behaviour". "error"
is not pondered about enough. Then again, I've never been taught programming
other than Jr. College where it was Pascal I think and everyone had to do it
(that's not important), so I don't know who failed the test in the course
and who didn't because I don't know what they/you are teaching.
Did you just say, "C++ exceptions used as a crutch to understanding the
problem"?
D
dragan
James said:
Thank you James for spelling it out explicitly to Mr. Child.
Given this
definition, I wouldn't call posting a web page on a subject you
know nothing about exactly "unprecedented"
"Duh".
Not that that that changes anything with regards to your
argument.
It does indeed if by "argument" you mean the little child suggesting that
_I_ have "an attitude".
D
dragan
White said:
While my method with you seems to have "subdued" you, my intention was only
show you what a baby you are. I think you may be a ticking time bomb. Get
some help. None of this shit is important.
J
James Kanze
Even within a single application, different types of errors will
require different types of handling. For that matter, the same
type of error may require different handling in different
contexts: a write error in a log file should probably be
ignored; a write error in the program output (e.g. when writing
the object file in a compiler) should probably result in the
program terminating with an error status (after clean-up---I
can't think of any case where a write error should result in an
abort).
Which is what I said. Most of the time, aborting is the
appropriate reaction, and it is the obvious choice for a default
action, but I'm well aware that there are exceptions: game
programs, for example, and possibly light weight GUI client
code.
I don't think anyone has reasonably argued that exceptions are
an "error managment strategy". First, as you say, they are a
just a mechanism---a tool to implement a strategy, and not a
strategy. And second, they only address one aspect of error
management: reporting. Error management involves three aspects:
detection, reporting and handling. Exceptions don't help in
detection, nor in handling. They just simplify reporting when
the error must be handled far up the call stack. (Which means
that they are of no use when the error must be handled
immediately.)
I didn't elevate anything. I'm just describing what exception
specifications do.
It is. Since the standard says it is. A function with an
exception specification "throw (std::bad_alloc)" may not exit by
any exception other than std::bad_alloc or an exception which
derives from std::bad_alloc. And the standard is authoritive.
Whether such a "contract" is practically useful is another
issue. In practice, the only contract expressible by exception
specifications which I've found useful is "throw()". In
otherwords, that the function will not exit by an exception,
period. Without it, you can't really write exception safe code.
I'm having difficulty parsing what you're trying to say. But
programming by contract certainly hasn't failed, and is still
considered a good thing in most circles. As for exception
specifications, they're just another part of the contract. So
one can't say that they've failed. What one can say is that the
contract they express is not all that useful (with the exception
of an empty exception specification---a no-throw guarantee).
I didn't write the definition of exception specifications. It's
in the standard.
I didn't write that, so I can't be sure, but a priori, an
"unexpected exception" is one that the programmer didn't expect;
that he wasn't prepared to handle.
No. I never said that. I've always argued that exceptions are
a tool, to be used when appropriate, but that they don't solve
all problems. (Many years ago, I was rather down on exceptions,
because everyone was constantly saying that as soon as compilers
supported them, all problems concerning errors would disappear,
and no one was addressing the real problems concerning
additional paths in the program flow that they raise. Since
then, our understanding of the issues has evolved.)
J
James Kanze
I think you misunderstood my statement. I explicitly said "Just
a linguistic nit". All I disagreed with was his use of one
particular word. And that use, while not formally correct, is
quite idiomatic in English: you'll quite often hear "an
unprecedented amount of X" as an exagerated expression of "a lot
of X". I don't think any amount of misconceptions would be
"unprecedented", given the number of sites on the Web by authors
who clearly don't understand what they're talking about. But
the site in question clearly falls into the category of sites
pontificating on subjects which the authors don't know very
well, if at all.
J
James Kanze
It is and it isn't. It is a goto, in the sense that it creates
additional possible program flow, which much must be taken into
account when analysing for correctness. It isn't, in the sense
that one of the major problems with goto is that it doesn't say
where we're coming from. Exceptions certainly don't have that
problem. And people like David Abrahams have successfully
addressed the issue of program flow, and least sufficiently for
exceptions to be acceptable in almost all code.
A meaningless statement.
Probably true in the case of the poster, however.
Easier than what?
No. C++ without exceptions is still Turing complete, so they're
not absolutely necessary. On the other hand, most large,
complex applications will be more difficult to write correctly,
and require more resources to develop, if you don't use
exceptions.
Yeah, they constrain it. That was the statement, i cannot se
how it can also be the reason.
I haven't seen anywhere where Google has officially said
anything. And I don't think it would matter if they did---if
you look at the HTML emitted by Google mail, for example, you
know that quality is not an important issue for Google.
(IIRC, Google was not represented on the standards committee in
1998, when the first version of the standard was adopted. And
the text concerning exceptions was finalized before that. On
the other hand, at least one person currently representing
Google was a memer at the time, for a different company.)
W
White Wolf
James said:
I guess you have seen my other post where I spell out what I mean. It
does not create a new path. It creates automagically the same path that
you would need to create anyway - using ifs and returning error codes.
And it only goes backwards, unlike goto.
I suppose it is, if the poster knows all C++ developers...
Yep, and perhaps a lot more people. But not all.
And IMHO Scott Meyers have managed to cover exceptions in surprisingly little space in
his 3rd edition. I do not state that exceptions are the cure for
everything, I do not even state that every program has to use them.
OTOH it is getting really tiresome how some think that exceptions are
the root of all evil, and they are demonizing a language features with
arguments that have been proven false over 10 years ago.
I guess easier than using exceptions... since that was the topic.
That I call necessary. I mean of someone wants to stay in business..
That is what I have said. AFAIK those people were already in the
committee. I did not mean Google itself.
Some was AT&T, some was Sun Microsystems...