| |||||||||||||
No thanks.No thanks.Posted Nov 9, 2012 9:47 UTC (Fri) by paulj (subscriber, #341)In reply to: No thanks. by Cyberax Parent article: Haley: We're doing an ARM64 OpenJDK port!
Sorry, but it's a fact that exceptions introduce implicit control-flow branch points at each statement, potentially even multiple such. That you can disagree with my comment on that point suggests either that you do not understand how exceptions are implemented, or else you somehow ignored the content of my comment in replying to it.
That coping with this requires structuring code in certain ways when using exceptions is true, but a different point, and it is still non-trivial at times because of the prior point. Just have a look at discussions on exceptions in C++ in constructors and destructors.
Note that I was not advocating for error return codes. That's a strawman argument you're incorrectly attributing to me.
(Log in to post comments)
No thanks. Posted Nov 9, 2012 10:22 UTC (Fri) by hummassa (subscriber, #307) [Link]
That is the point:
> Sorry, but it's a fact that exceptions introduce implicit control-flow branch points at each statement, potentially even multiple such.
THAT IS NOT A FACT AT ALL.
Those implicit control-flow branch points WILL HAVE TO BE DEALT WITH ANYWAY, they were already there. Only without exceptions you have to deal with them all at all positions in your code. Explicitly. You are writing code that is scaffolding code, not code that does what the program actually needs to do.
When you use exception, you write only the code that does what the program actually needs to do, with some sanity checks here and there. You follow the sanity rules, you are safe.
For instance, every time you open a file things can go wrong. Supposing you have a function call hierarchy main -> f -> g -> h, and h() wants to open a file, one of the following will happen:
1. you (generic "you", ok?) won't check open() results, will proceed as if the file was open, and undefined and terrible things will happen;
2. (try#2) you will check open() results, return an error code, g() does not check for the error code and proceeds, hilarity ensues;
3. (yes it finally works) g() checks h() error code, f() checks g() error code, main() checks f() error code, prints a suitable message.
4. (despair happenning) you have to call i() from g() and j() from f() and both have to open files. At this point, if you don't forget anything (you have to do every of these checks yourself, manually) you have a program that is at least 25% scaffolding.
With exceptions, one of those will:
1. open() throws, _main() aborts and prints "unexpected exception". The program already works.
2. (let's make this pretty) you put a catch() block on main(), print a pretty message cerr << "file " << name << " could not be open". The program still works.
3. (down the road) you have to add i() and j() and the program still works. No need to repeat step 2.
> Note that I was not advocating for error return codes.
No, but you are differentiating "implicit control-branch points" from "explicit" ones and it does give that impression. My point is that: implicit control-branch points are there anyway (you open a file, things can go wrong in the process), and dealing with them implicitly is better then explicitly.
Yes, dealing implicitly with exceptions means that sometimes you have to be exceptionally (ha!) safer (constructors/destuctors). But it just helps you to clarify your code and tell better when things can go wrong.
No thanks. Posted Nov 9, 2012 10:29 UTC (Fri) by paulj (subscriber, #341) [Link]
So the control-flow branch points which you disagree exist have to be dealt with anyway? So they don't exist but they do.
There are other ways to deal with errors, besides exceptions or error return codes. You can design the underlying, called-into code to explicitly follow a state machine, and have idempotent error state. Calling code then do a number of operations on such objects, and check at the end whether they succeeded or not, and if not, query the reason for the error.
No thanks. Posted Nov 9, 2012 16:35 UTC (Fri) by HelloWorld (guest, #56129) [Link]
> So the control-flow branch points which you disagree exist
Did you even read what he wrote? He didn't say they don't exist, he said that they exist regardless of whether you use exceptions or error codes to handle errors.
No thanks. Posted Nov 9, 2012 23:40 UTC (Fri) by nix (subscriber, #2304) [Link]
Each statement? If only it were so easy. At each statement, each function call, and each potentially overloadable operator. The number of abnormal edges can get ridiculous. There could be *dozens* in a single thing that looks like one statement.
No thanks. Posted Nov 10, 2012 3:26 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]
Nope. The number of statements where special exception handling is needed is SMALL. Basically, only the code that works with external or shared long-living resources.
No thanks. Posted Nov 10, 2012 10:21 UTC (Sat) by paulj (subscriber, #341) [Link]
There you go again saying "Nope" to something that is factually correct. At this stage it's hard to conclude anything other than that you simply don't understand how exceptions work under the hood.
No thanks. Posted Nov 10, 2012 16:10 UTC (Sat) by nix (subscriber, #2304) [Link]
It's clear he's never written any significant body of exception-safe code in C++, that's for sure. (Hint, Cyberax: consider a simple RAII object which allocates some memory in its constructor, in two tranches, with a single assignment between. Now consider that memory allocation can throw bad_alloc, as can the invocation of the assignment operator, if not elided by the compiler, as it can sometimes be -- and consider that if this is templated, you have to consider that *every possible point* that might throw exceptions, will throw exceptions, since you don't know what types you'll eventually be dealing with.
That memory allocation is not a shared resource except inasmuch as the heap is shared -- in which case you have to consider almost *everything* a use of a shared resource -- but you still need to consider the semantics of exceptions in order to figure out how to avoid a memory leak. And this soon gets thoroughly unobvious.)
No thanks. Posted Nov 10, 2012 21:48 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] >Hint, Cyberax: consider a simple RAII object which allocates some memory in its constructor, in two tranches, with a single assignment between.
#include <stdio.h>
#include <memory>
#include <stdexcept>
class tracer
{
public:
tracer() { printf("Constructing\n"); }
~tracer() { printf("Dying\n"); }
};
class tester
{
std::auto_ptr<tracer> t1_;
std::auto_ptr<tracer> t2_;
public:
tester()
{
t1_=std::auto_ptr<tracer>(new tracer());
throw std::runtime_error("Test");
t2_=std::auto_ptr<tracer>(new tracer());
}
};
int main()
{
try
{
tester t;
} catch(const std::runtime_error &ex)
{
//Print exception info
}
return 0;
}
cyberax@cybmac:~/work$ ./a.out
Constructing
Dying
And your point is?
Consider that you have to deal with exactly the same crap if you DO NOT use the exceptions. EVERY function you invoke can cause error conditions (such as out-of-memory). Now please rewrite my example without exceptions, providing the same level of guarantees and functionality.
No thanks. Posted Nov 10, 2012 23:06 UTC (Sat) by nix (subscriber, #2304) [Link]
You really don't understand, do you?
Consider just these three lines of your example:
t1_=std::auto_ptr<tracer>(new tracer());
Let's replace the stupid throw with something more likely to be actually seen in practice, say:
t1_=std::auto_ptr<tracer>(new tracer());
Now... if any of those constructors but the first throws, what do you do about it? If, for whatever reason, you cannot use auto_ptr (which is, to be honest, simply pushing off the RAII memory-allocation overhead to something else that has already done all the work) how do you prevent the earlier-allocated ones from leaking? That's right, you have to free at appropriate times in a catch handler. Now figure out which bits can throw. It's hard. It's very, very hard. I recommend Scott Meyers's Effective C++ books for more than you can possibly stomach on this (I wish I could reread mine, but I loaned them out and they never came back, I'm sure you know how it is).
No thanks. Posted Nov 10, 2012 23:22 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]
Try it. I really mean it - try it. It would work just fine. Everything will be correctly destroyed.
>If, for whatever reason, you cannot use auto_ptr (which is, to be honest, simply pushing off the RAII memory-allocation overhead to something else that has already done all the work) how do you prevent the earlier-allocated ones from leaking?
Of course, if you really don't want to do it then you'll have to do the try..catch dance. Exactly like in C where ALMOST EVERY function might result in error and the most common pattern of error handling is "goto err_exit". That's actually why glibc handles OOM by calling abort() - it's simply too complicated to make everything in C error-safe.
PS: I had actually written a simple model verifier to verify my own collection library for upholding exception guarantees. That means that I've obviously read Sutter, Meyers, Stroustroup, Alexandrescu and quite a lot of other C++ writers.
No thanks. Posted Nov 10, 2012 23:25 UTC (Sat) by foom (subscriber, #14868) [Link]
> Now... if any of those constructors but the first throws, what do you do about it?
You don't have to do anything, because auto_ptr's destructor takes care of it for you.
> If, for whatever reason, you cannot use auto_ptr ( which is, to be honest, simply pushing off the RAII memory-allocation overhead to something else that has already done all the work
That's the whole point! You *always* just use auto_ptr (or another smart pointer, e.g. unique_ptr) to take care of it for you! That's exactly why RAII is so nice, and has been best practice in C++ for years!
No thanks. Posted Nov 11, 2012 9:32 UTC (Sun) by paulj (subscriber, #341) [Link]
That smart pointers are required exemplifies the "non-trivial" observation made of exception using code. And remind me again, how long have these been available as part of the standard C++ environment?
No thanks. Posted Nov 11, 2012 10:37 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]
Since at least 80-s. The problem was mostly in old C programmers who don't know better.
No thanks. Posted Nov 11, 2012 12:53 UTC (Sun) by paulj (subscriber, #341) [Link]
Rubbish. I have books from the 90s on C++ that fail to mention smart pointers anywhere, written by C++ committee members.
Could good C++ programmers have created their own smart pointers in the 80s? I guess so. My strong impression though is that C++ programmers would have been *way* ahead of the state of understood wisdom in the C++ world at that time. My impression
To claim smart pointers are trivial, widely understood techniques since the 80s stretches credibility somewhat. If they're so trivial, so widely understood for so long, why did it take 20+ years to standardise some? Why is an only relatively recently standardised form of smart pointer already being deprecated in the next C++ standard? (auto_ptr for unique_ptr). My sense is that smart pointers are so trivial that even C++ standards committee members hadn't really fully grokked the implications of copying, moving and sharing them until relatively recently - but I guess they're just "old C programmers who don't know better".
Unfortunately, in the real world, many programmers just aren't quite as brilliant as you.
No thanks. Posted Nov 11, 2012 13:04 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]
> Rubbish. I have books from the 90s on C++ that fail to mention smart pointers anywhere, written by C++ committee members.
[citation needed]
> Could good C++ programmers have created their own smart pointers in the 80s? I guess so. My strong impression though is that C++ programmers would have been *way* ahead of the state of understood wisdom in the C++ world at that time. My impression
http://www.stroustrup.com/bs_faq2.html#finally
>If they're so trivial, so widely understood for so long, why did it take 20+ years to standardise some? Why is an only relatively recently standardised form of smart pointer already being deprecated in the next C++ standard? (auto_ptr for unique_ptr).
However, Boost and other libraries had no shortage of various smart pointers.
No thanks. Posted Nov 11, 2012 14:56 UTC (Sun) by paulj (subscriber, #341) [Link]
Herbert Schildt, "C++ Nuts & Bolts for Experienced Programmers", Osborne McGraw-Hill, 1995. (Yes, Schildt has gotten flack for technical errors / flaws on C++ in his books, and yes, this book wasn't intended to be a reference).
When was Boost created? late 90s. Before Boost there was the HP and SGI STL, which I gather inspired the standardised STL (and Boost?), and iostream. That work dates from the early 90s AFAICT. The SGI STL page doesn't seem to have any kind of smart pointer, dated 1994. C++98 has the auto_ptr, but it apparently is flawed. The early Boost pages reference this: http://web.archive.org/web/19991222182604/http://www.boos... which references books discussing smart pointer programming *patterns* from '92, '94.
I know this stuff is all trivial to you, but it does seem to me that it took about 10 to 15 years (80s to mid/late 90s) for leading C++ programmers to agree on patterns for dealing with exception safety, such as RAII, then getting some kind of smart pointer support in the language (standard or generally available libraries) in order to cope with remaining pitfalls in C++ RAII+exceptions. That smart pointer support then needed further refinement in the mid/late 90s and early 2000s to get to where we are today.
That doesn't quite suggest to me that this stuff is quite as trivial as you suggest to is. Finally, even with smart pointers, I still don't find exception handling code that uses them to be non-trivial! However, you do seem be a superior breed of programmer to the rest of us, so perhaps that's the reason for the discrepancy in views ;). (Intended as a gentle jibe, I hope you'll accept it in that spirit).
No thanks. Posted Nov 12, 2012 2:05 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
>Herbert Schildt, "C++ Nuts & Bolts for Experienced Programmers", Osborne McGraw-Hill, 1995. (Yes, Schildt has gotten flack for technical errors / flaws on C++ in his books, and yes, this book wasn't intended to be a reference).
He's not a member of C++ committee.
>When was Boost created? late 90s. Before Boost there was the HP and SGI STL, which I gather inspired the standardised STL (and Boost?), and iostream.
Exceptions appeared in GCC 2.7 in 1997, I think. Before that there was little reason to use them and to create best practices for them. Though the usefulness of RAII was understood earlier.
In Java exceptions with try..finally also appeared at about the same time. But without RAII.
No thanks. Posted Nov 12, 2012 14:35 UTC (Mon) by paulj (subscriber, #341) [Link]
Well, Schildt's wikipedia page says he was involved in C++ standardisation in the 90s. I don't know myself if that's correct or not.
As for exceptions, they were developed in the late 80s, standardised in the early 90s, and there were commercial compilers supporting exceptions since at least '92 apparently. See: http://www.stroustrup.com/hopl2.pdf. The release history of GCC possibly isn't that relevant, a number of proprietary implementations of C++ had more significant usage than g++ back then iirc.
Anyway..
No thanks. Posted Nov 12, 2012 14:38 UTC (Mon) by paulj (subscriber, #341) [Link]
Oh, the '95 Schildt book has a section on exceptions.
|
|||||||||||||