on Fri Oct 14 2011, Andrew Hundt <athundt-AT-gmail.com> wrote:
Is throwing an exception going to turn an incorrect program into a
correct one?
If you catch that exception and do something reasonable, would it not?
No. "Reasonable" doesn't mean you fulfill your original intention/specification. You don't normally write specifications that say, "...unless the code is wrong, in which case I'll do something reasonable,"
I'm fairly certain that writing specifications this way is quite common.
I was asking about you, personally.
For instance, consider a program that catches exceptions and crashes, then generates and sends a bug report to the creators. Does that application not catch when the code is wrong, then do something reasonable?
Its specification doesn't say "do something reasonable;" it says "send a bug report to the creators."
Of course this is not correct behavior with respect to the original goal, but I would argue that is is correct behavior with respect to a secondary goal of finding incorrect behavior that prevents reaching the original goal.
Sure, but exceptions are a poor way to get that effect.
Furthermore, I don't believe I am being very original with this idea. Java has the ArrayOutOfBounds exception. Please, I beg you not to take this as the belief that Java is correct. I am simply unconvinced by your argument and I am playing devil's advocate by pointing out an example counter to the point you are making.
I don't know what to say. Java is a mostly-different story; they have no undefined behavior in the language, so they have to do something else. IMO using EH to deal with programming errors is usually a mistake, but it's one that's been repeated far and wide.
More precisely, it avoids some undefined behaviors, which has some security benefits. That's why I proposed the SEMISECURE mode.
Why should the mode be SEMISECURE by default, and not a RELAXED_SECURITY mode for when you absolutely need the highest performance?
Everybody wants a different default; I'm not here to argue about that except that I'll say people get upset when they turn on all the optimizations and then pay for checks they weren't expecting.
also, what is the disadvantage of providing, push_back(), checked_push_back(), and unchecked_push_back(), where a policy or struct tag allows the checkedness (pardon my word frankenstein) to be decided at either the instantiation or the call site, respectively?
Creeping—nay, rampaging—complexity.
To draw an analogy, designing code to use RAII can sometimes incur a performance penalty with the benefit of preventing a failure to release a resource. Of course you can always "just free" that resource by hand, but changes in one portion of an application can have unforeseen consequences in another to those who are dealing with a small portion of a very large or complex system. Therefore it has become commonplace to pay a small penalty for the benefit of preventing problems. In this case, that problem is undefined behavior, and the penalty is the checks. Perhaps an out of bounds error does not meet the complexity level required for such a cost to be worthwhile, but if I am not mistaken myself, it is one of the most common mistakes made by anyone. However, this does not prevent one from making the other choice, and calling the unchecked version when they absolutely need the performance.
The core of what I am saying is that checks + exceptions make it easier to find, prevent, and/or report problems.
The checks are not the problem; the exceptions are. And they don't help with finding, preventing, or reporting problems.
There are a some items I would like to verify so I can clarify my understanding of your argument.
First, I believe that you are saying that code is already incorrect when it goes out of bounds,
Probably.
so you might as well just let it keep running with undefined behavior unless a special SEMISECURE flag is set.
No.
Furthermore, by the time you reach the point where I am proposing that an exception be thrown, the code is already incorrect, therefore the exception will never prevent an error, and thus the exception should not exist. Is this correct?
That's one way to look at it, but it's not what I said. The main problems are the ones I cited before in this thread (you can go back and look them up).
What are the metrics by which you define an exception as both incorrect and/or worse? What is lost by using an exception? Does it break a convention, reduce performance, break purity, or upend general happiness?
All answered already in my first posting in the thread. -- Dave Abrahams BoostPro Computing http://www.boostpro.com