Hacker News Reader

Comment by shin_lao | Hacker News Reader

It looks mainly looks like a rant on exception, but nothing forces you to use exceptions with C++. You can even allocate memory in a way that doesn't throw.

We don't use exceptions for the reasons described in the article (and many others), we use boost::system::error_code instead.

But that's for the first half of the article, and the OP admits that he simply gave up on exceptions.

As for the part about half-initialized state, I think the problem is that the author is trying to do OOP in C++ without exceptions. Perhaps a more generic programming approach would solve his "half initialized problem".

Don't want to sound like a snob, but it really looks more like a design problem than a language problem.

View on HN

> nothing forces you to use exceptions with C++

But unless you eschew every other C++ library including the STL, etc. other code is going to (potentially) throw exceptions whether you like it or not. C++ has exceptions built in at its most basic level - operator new() throws bad_alloc. Are you going write C++ with using 'new'? Are you going to ensure that no library you use uses 'new'?

I used to follow Herb Sutter's "guru of the week" problems and a large percentage of them were "how many exit paths are there from this block of code?" which would usually be a function about 4 lines long. Typically there were > 20 ways the function could exit, taking into account all the various operator overloadings, implicit constructors / type conversions, etc. And that was using code that itself usually had no use of exceptions - their mere presence in the language caused the problem.

I have seen exactly 0 programs that ever wrapped new calls in try/catch blocks to catch bad_alloc. If you can't allocate memory, you are likely going to need to exit anyway.

You can write quite a lot of C++ without ever using exceptions since exceptions. There are people who write exception-happy code. I tend to prefer only using exceptions for exceptional events like where the the only other option would be for the program to exit. I throw an exception in the hope that someone upstream will catch it and be able to handle it.

Honestly, if you throwing exceptions constantly as part of your normal executing code path, you're going to drive yourself crazy.

Agree. I've often opted out of using exceptions in C++ for high performance or low level systems. This usually meant coding C in C++, but it was still great to have namespaces, the STL, Boost libraries, and stricter static typing. Too often it seems that people think they have to be at one extreme or the other of the C - C++ spectrum - why not something in between?

> Don't want to sound like a snob, but it really looks more like a design problem than a language problem.

I stopped reading about halfway through as most of the code samples reinforced this.

I agree, this is just a rant on C++.

Coming from Java world, I can tell that it is nice being able to raise exceptions from the constructor.

However, switching from C++ to C is absurd. C++ is (mostly) a super set of C. Whatever you want to do in C, in C++ is also possible.

If there are some C++ features (exceptions, classes, contructors, etc.) that are making his coding task more complicated, he should simply stop using those features and refactor his code.

There is one advantage to writing in plain ANSI C and it is that you get it to compile and run on anything.

I wouldn't say absurd. Certainly you can use C functions in C++. But if you want to eliminate the use of most or all C++-only features, the only way to guarantee that is to not use C++. White or blacklists can be circumvented, intentionally or inadvertently.

I agree.

For me it looks more a blame the tools rant, instead of looking at improving the design.

All the alternatives proposed would work as well in C++, with the added benefit that C++ has a better type checking than C.

Reply on news.ycombinator.com