Hacker News Reader

Comment by sillysaurus3 | Hacker News Reader

Yes, RAII is the only way to make an exception-safe class. Good luck doing it. It's not easy. I know; I've tried. There are all kinds of corner cases and special considerations that you have to take into account. People have written huge tomes about that exact topic detailing exactly why it's a hard problem and why you're probably not going to solve it correctly by accident. You're far more likely to introduce a memory leak than to make your class exception safe on the first try. That's my point. That's why C++ is overly cumbersome unless you ignore most of its capabilities, like exceptions. And that's why you can simply ignore C++ and not miss out on much. If performance is your only reason for rigorously sticking to a mental model, it's likely that your mental model is a premature optimization.

View on HN

"Good luck doing it. It's not easy. I know; I've tried" Completely unsupported assertion (no pun) without evidence. Other people have tried it, and have succeeded. I could start listing all the software written in C++ that you use in your everyday life, perhaps 100's of times a day... but that'll quickly exhaust my word limit for this post.

"That's why C++ is overly cumbersome unless you ignore most of its capabilities, like exceptions."

Complete non sequitur. Exceptions are not "most of C++ capabilities". In fact, you can refuse to catch or throw exceptions for 99% of your (millions of lines) of code and still end up with a very large, stable code base running a large portion of the internet. Ask Google.

Today, there's pretty much no viable alternative to C++ for writing large scale, high performance systems with reliable performance guarantees. You could do it in C if you have a religious anti-C++ agenda but that would be like cutting off your nose to spite your face, and you'll end up in a horrible mish-mash of macros and generated code all over the place for a project with any level of complexity. Rust or D might get there some day if they manage to attract a solid community and big corporate backing. But they are certainly not there yet.

> you can refuse to catch or throw exceptions for 99% of your (millions of lines) of code and still end up with a very large, stable code base running a large portion of the internet.

The point is that these features are infectious. If you don't want to throw exceptions, how do you handle a failure in a constructor? And then if you abandon constructors, other C++ features are unusable without them. And so on.

Googler here. We avoid doing "work" in constructors as per the style guide: http://google-styleguide.googlecode.com/svn/trunk/cppguide.x...

Yeah, that's pretty much what you have to do, and go back to a C-style init method. But then you've lost the benefits of RAII, and you can't necessarily use those types with templates (which won't know about your init method).

> Exceptions are not "most of C++ capabilities".

To add to this point: There are C++ frameworks such as Qt who don't use exceptions at all! And what impressed most: When writing a Qt application, you don't even miss exceptions. You don't have to resort to C-style return value checking all over your code. How is that? It took me some time to figure this out, but I believe it is because Qt applies the "Null Object" pattern consequently - down to the deepest depth of their framework,

You could do it in C if you have a religious anti-C++ agenda but that would be like cutting off your nose to spite your face, and you'll end up in a horrible mish-mash of macros and generated code all over the place for a project with any level of complexity.

Have a look at Tarsnap's source code.

Actually that statement has a point. Have you ever tried implementing std::vector and java.util.ArrayList and comparing the two implementations? One of them is trivial, the other one is most certainly not. One of the reasons is exception-safety guarantees. I'll leave it for you to figure out which is which.

What were these corner cases and special considerations you ran into?

I wouldn't call Herb Sutter's _Exceptional C++_ a huge tome and it seems to be the standard treatment of exception safety.

It's 240 pages of knowledge that you can completely do without, and it's a book called "47 engineering puzzles." The puzzles, of course, are entirely exception-related.

I'm not saying it's impossible to write exception safe code. I'm saying that you can write code without exceptions without being worse off for it.

We're talking about the same book, _Exceptional C++: 47 Engineering Puzzles, Programming Problems, and Solutions_, by Herb Sutter. The takeaway I had from reading that book (a long time ago) was just to use RAII religiously, which also tends to make other things easier.

So I'm curious about why you think RAII makes writing exception-safe code difficult?

Sorry for the confusion. I meant that writing exception-safe code is difficult, not that RAII makes it difficult to write exception-safe code. I should have been clearer about that.

The book is excellent. For anyone who wants to use C++ exceptions, it should be required reading. But as someone who has gone through that gauntlet, I feel that I probably would've been better served by spending my time on something other than mastering the finer points of exceptions.

The reason I started talking about C++ exceptions in the first place is because, in my experience, when someone is very pro-RAII (like the original commenter I responded to), they also tend to be pro-exceptions. This isn't always true, but on average, it seems like either people prefer both or prefer neither.

Writing exception-safe code is certainly one of the hardest challenges available in C++, so if you enjoy a good challenge, then it's hard to do better. But if you're just looking to design large-scale systems, it seems like exceptions are unnecessary, as Google has demonstrated by banning the use of exceptions in their codebases.

In my experience, by refraining from using exceptions, it's possible to design large codebases more quickly, with fewer bugs, and without losing any safety or extensibility. However, this is simply my personal experience, and it may be mistaken to generalize this into a claim that all codebases among all C++ teams should refrain from using exceptions.

So, that's all I meant. I was also in excruciating pain yesterday due to a certain tooth that decided to segfault in my mouth, which may have contributed to the adversarial nature of my writing style. I feel bad about how I came across, and I sincerely apologize for it. No excuses, though: I should've done better.

> either people prefer both or prefer neither.

exceptions (specifically, exceptions from constructors) are part of what RAII is, so it's only natural that people "prefer both".

As another personal anecdote, in my experience working with a large (175MLoC at last count) mostly-C++ codebase, I can't imagine how painful it would have been if the code didn't use exceptions.

Their style guide http://google-styleguide.googlecode.com/svn/trunk/cppguide.x... is sheepish about it. The authors seem to believe using exceptions would have been better, except they found themselves beyond a critical mass of bad code that would fail or leak on a throw, and now they can't fix it all or throw it away.

I can't understand how a correct init method could be easier to write than a ctor, given that the compiler is required to generate code that knows which of your base classes and fields are already initialized at any point they could fail, which you would have to do yourself after moving to an init method, as well as losing the guarantee you can't silently ignore an error by forgetting to check for it.

Reply on news.ycombinator.com