However, what's great for avoiding straightforward failures becomes a nightmare when your goal is to guarantee that no undefined behaviour happens. The decoupling between raising of the exception and handling it, that makes avoiding failures so easy in C++, makes it virtually impossible to guarantee that the program never runs info undefined behaviour.

I do not see from where that conclusion originates. Functions that are being called (and potentially fail with an error) should be decoupled from the caller. It doesn't matter if the error is propagated as an exception or a simple code. Error codes can be silently ignored, while exceptions can't, which means you are more likely to introduce bugs while using error codes. If you ignore an error condition and go on, your process might go into undefined behaviour territory. An exception will propagate to the nearest handler, cleaning every object along the way.

int rc = fx ();
if (rc != 0)
handle_error ();

int rc = fx ();
if (rc != 0)
throw std::exception ();

These are not equivalent - far from it.

The problem with that is that you have no idea of who and where is going to handle the exception.

As it should be. Why should you care who handles the error? In your example, the function fx() obviously doesn't care - just informs that an error happened. You are advocating coupling callees with callers.

(code examples)
It's far more readable and — as a bonus — compiler is likely to produce more efficient code.

First - it's not equivalent, since you also need to jump out after the error in C. The most common way I see with C programmers is using goto for that task (because you usually need to release resources and there is no RAII in C), which isn't readable at all and can introduce bugs. Can you recall scoping rules with goto out of your head? I don't think so.
Second - if you forget about jumping out, your code will just go on thinking no error was generated.
Third - you have no evidence of the compiler producing that much better code for the programmer to care. When it comes to trading safety for efficiency, you should go with the safety the exceptions provide you with.
Fourth - I find exceptions far more readable - "if X happened, generate error Y". What's not readable about that?

However, it doesn't end there. Consider the case when the exception is not handled in the function that raises it. In such case the handling of the error can happen anywhere, depending on where the function is called from.

That is exactly the point. Callee should not care who handles its errors. When a C function returns an error code, it doesn't care who handles it. The same logic applies to exceptions. Once again you are trying to tie callees with callers.

As you fix individual bugs you'll find out that you are replicating almost the same error handling code in many places. Adding a new function call to the code introduces that possibility that different types of exceptions will bubble up to the calling function where there are not yet properly handled. Which means new bugs.

If you don't handle an exception, the default handler will (terminating the process with an error message). If you don't handle an error code in C - nothing will inform you of that. Your process will go on in an erroneous state thinking everything is ok. Good luck debugging such errors.

If you don't give up on the "no undefined behaviour" principle, you'll have to introduce new exception types all the time to distinguish between different failure modes. However, adding a new exception type means that it can bubble up to different places. Pieces of code have to be added to all those places, otherwise you end up with undefined behaviour.

First - you won't end up with undefined behaviour, since the exception propagation is well defined by the Standard. You'll end up with the default handler which will show you the error message.
Second - similar logic applies to error code. If you create a new error code, you need to handle it. If you don't, your process will silently go into some undefined state.

Well, the problem is that exception specifications are just a tool to handle the problem of exponential growth of the exception handling code in a more systematic manner, but it doesn't solve the problem itself. It can even be said it makes it worse as now you have to write code for the new exception types, new exception handling code *and* new exception specifications.

That really doesn't make sense. What is that problem that exceptions don't solve and error codes do? Please define it. Also - what exception specifications? If you're talking about throw(…) in declarations, those were always a bad idea and were discouraged. Now, they're deprecated and should never be used.

Consider what happens when initialisation of an object can fail. Constructors have no return values, so failure can be reported only by throwing an exception. However, I've decided not to use exceptions.

And that is your problem there. You decided to go against the language features and you ended up with some absurd semi-constructed states, which you need to handle manually. If you followed the language, that is:

• An object is considered constructed (initialized) when its constructor returns with no exception.
• With RAII, all your resources should be released in the destructor, making resource handling automatic.

you'd find that your code is both safer and simpler. Object could be either constructed or not. Error would be signalled on failed constructions. Resources would be automatically freed.
Instead you made a little hell for yourself, where you need to take that semi-constructed state into account, potentially introducing bugs.

Now you say: But that's just a consequence of your artificial restriction of not using exceptions! If exception is thrown in a constructor, C++ runtime cleans the object as appropriate and there is no 'semi-initalised' state whatsoever!

Fair enough. However, it's beside the point.

No, it's not beside the point. The whole point is about you fighting the language, instead of using its features to make safe code.

And that is not a reasonable option for an infrastructure component with the need to be very robust in the face of failures.

As a person who is making such "infrastructure components", as you called them, I claim you are totally wrong on that front. Proper usage of exceptions and proper usage of language features make your code resistant to failures and very safe. Fighting against it is what lead you to this mess, and you try to blame the language for it.

Moreover, even if initialisation wasn't a problem, termination definitely is. You can't really throw exceptions in the destructor. Not because of some self-imposed artificial restrictions but because if the destructor is invoked in the process or unwinding the stack and it happens to throw an exception, it crashes the entire process.

Right - you should not throw form the destructor (they are noexcept now, in fact). Try to think about more closely - you are releasing resources and you encounter an error. If this is not critical and the process can continue, you can safely not throw. If it it's critical, you should terminate because, well, it's critical.

Thus, if termination can fail, you need two separate functions to handle it

No, just follow RAII. You'll get a safe and reliable way of automatically releasing resources in a single function - the destructor.

However, once you introduce separate init functions, the number of states starts to grow.

So you see why your idea of semi-states is bad. Why do you advocate it then?

With objects like these it's almost impossible to guarantee predictable behaviour.

You created a problem which doesn’t really exist, if you follow the simple rules. You then created a really bad workaround to that problem. And, in the end, you list the reasons why your solution is bad. That's absurd.

To summarise the above, I believe that requirement for fully-defined behaviour breaks the object-oriented programming model. The reasoning is not specific to C++. It applies to any object-oriented language with constructors and destructors.

Pretty much every piece of code, which is made with proper fashion, proves you wrong. Don't fight the language, but learn to use it to your advantage. You'll find all your problems are really artificial.

The first point of yours was that certain exception patterns are awkward. I agree - so simply don't do it this way. Don't use exceptions for control flow. If, when throwing, you need to know who catches the error then it is a misuse of exception handling and too tight of a coupling. Exceptions are to be treated as special return values that automatically bubble up as a default behavior.

If an operation is expected to fail sometimes, and meaningful actions can be taken as a result, then error codes as return values are totally reasonable. They mix with exceptions well.

For destructors being invoked at the end of the block, you can do that too with C: http://echorand.me/site/notes/articles/c_cleanup/cleanup_attribute_c.html

For virtual methods, I agree it's quite painful, but for a schema that's working in years you can look at gobject and how they do it. For a single class there are two data structures, the instance struct and the class struct. The class struct is where you put the vtable.
That means you have a single vtable for one class instead of having one vtable per-instance.

While exception do allow the de-coupling of handling from cause, they don't heve to be used that way. You can stop exceptions propagating out of any block and handle, assert or convert to c-style at whatever level you want.

In an earlier example you talked about calling a third-party function that could generate any (to you) unknown exception, so just wrap it in a try…catch(…) and convert to a return FAIL or asssert, whechever you prefer. How is not using exceptions going to help in this situation?

Almost all of C can be mis-used just as easily as C++. At least with exceptions, if you do miss one it will propagate out and you will know, with a missed return check, you may never find out.

Abstraction is a technique for managing complexity but these "modern" high-level features often results in more work for machine and developers without any additional values.

code like this:

XX* p = new(std::nothrow) XX(..);

if (nullptr == p) { handle_error(); }
else {
auto ret = p->init();
if (OK != ret) { handle_error(); }
}

if ( p->init_succ() ) {
auto ret = p->deinit();
if (OK != ret) {
handle_error();
}
}

…

From there, it's a matter of allocating from that particular pool (one of the reasons I think interfaces like malloc() are broken, is because there is no way to supply a generic pool of memory, or to seize a pool from malloc() and have it manage allocations within it).

More sophisticated memory handling would benefit C.

If it was talking about C vs. C++ it would make no sense. C is (more or less) a subclass of C++.

As for C++11, C++14 etc., by growing the featureset it's making the problem even more grave. Idiomatic C++ today is definetely a bigger mess than it used to be in 1995. Soon enough it will be as messy as Java :(

"This is great when you are OK with 80% or 90% solutions. Errors are sparse and handling them correctly in 90% or cases can mean the problem will be never hit, especially if the program is not used very widely."

However, even a hello world application doesn't have a <10% (we're sayingthat only 10% or less of the logic in the application doesn't handle every single error that can happen absolutely perfectly…) fault ratio; not even the UNIX kernel has a <10% fault ratio….there's always a way to break stuff, why fix it until it needs to be fixed? At which point you know the issue, and how to handle it…. I can hack Windows and activate it any day of the week -> switching to another language isn't going to stop that.

Move to C++14, not to plain C. C++ i s an extension of C -> You can use any part of C in C++ -> including C syntax. In fact, most beginner C++ courses don't even teach you any C++ at all - it's all C syntax run under a C++ compiler. So in essence it doesn't even make sense to say C would have been better than C++….

The true trick to any lower level programming language is architecture. How you design your application will make it or break it -> regardless of the actual language used.

I'm disappointed seeing all the comments about replacement languages for C; why aren't people working on replacing POSIX APIs with C++ methods over C methods? Why isn't anyone working on replacing C altogether with C++ rather than just letting it be an extension? You know…making a true C++ runtime in Assembly instead of requiring a C runtime over Assembly? Bet ya that'd be much faster than Go and we wouldn't have to learn any new languages or APIs (well, for the most part - syntax would certainly change a bit for some system methods).

Donate me 100k and I'll do it myself - just give me a few years…

The father of C++ isn't dead yet, its only getting better and better and better and better and better.

You just need to take the time to work it out. It takes YEARS to LEARN programming, not days -> if you are looking for a single day answer switch to .NET or some other auto-generated non-sense and let the quality speak for itself (but I'm sure you know this already ^^).

Another alternative to is rust, being developed by Mozilla. It's focus is on being very fast and very safe. The first stable version is due to be released within the next few months and from the little bit I've played around with it, it looks promising as an alternative to C that can be used to build system programs that need to be robust.

C++ Exceptions: Nothing is stopping you from using return codes in your app/system. You can infact turn them completely off with a command line option with some compilers, and simply not use them in the rest.

Object Inititalizers: Use them where they make sense, and just use structs instead of objects for the rest of the cases and where the compiler-supplied constructors are not useful. The STL is pretty damn useful, I don't see the point of doing without it for the points you raised here. They are valid, but C++ is a buffet table, use what you want, ignore the stuff you don't.

And to Adrian above: "…This is the C way, but with a better standard library." Fine, but you don't explain how Go's "standard library" is better than C's. And by standard library, do you infact mean C's standard runtime library? Yes, I can agree with you that some of C's "standard" runtime libs are lacking, but you're not limited to using them. I do embedded programming and using GNU libc is usually not optimal in most cases, I often use eglibc and if I think C++ is a better fit for a problem I'll use uSTL.

Go is a good language, a real contender as an all-around replacement for C in general for a compiled solution. But in the specific case of embedded programming, most of the companies I deal with will probably not even look at it for a long time, if ever. Aside from the support issues its still slower than C.

But I don't think C is the solution. Because in C++, if you don't want the "semi-initialized" state, you can choose not to use constructors and destructor. Writes Foo::init() and Foo::term() instead.

The main reason "semi-initialized" state is introduced (at least for me) is that I want to ensure that when init() is called twice, init() can detect it and handle it gracefully (instead of possible memory leaking). And with the C version which allows random data in the struct, I cannot achieve this.

What's your solution to prevent double initialization in C version of init() ?

Common sense is not a contractual guarantee that an error could only happen one way.

It prompted me to write something called tenacious_malloc(), which reserves some space (nominally 1MB) at the start of the program, which it uses as a pool to allocate memory from for other things that can't run out of memory. I hope you can make use of it, or maybe it will provoke further thought and development.

http://stackoverflow.com/questions/21172440/strategy-for-recovering-from-null-malloc-due-to-memory-exhaustion

Njoy!

Just sayin….

I was using the Lazy Pirate pattern in ZMQ, and noticed that even a single client sending a 32 bit int as data, and returning one from the lp_server stalled for 8-20 seconds at random times. I'm guessing that's the HWM getting hit, but it got me looking at Stream Control Transmission Protocol, which got me to thinking it would sure be great if some messaging primitives like ZMQ could be included in Linux. Good to hear that you have concluded the same it seems, and thus CrossRoads.

I've been writing code for the VOIP industry the last 8 months, after years writing derivatives code for Wall St, and get the need for no "undefined behavior". Also, we've been extending open source software like Kamailio with a hybrid of C & C++, where the only part of C++ we use is the STL. Since these are generally watch-dog apps that monitor large Kamailio farms, linked by ZMQ, this is a very nice approach, as our staff's expertise is mostly in C, and encapsulation and polymorphism arising from the use of classes is just not needed.

The one serious objection I have to C++ is it dropped anonymous structures, which was a horrible decision taken with very little deliberation. Without them maintenance on structs in code is much more difficult, and needlessly so.

Best of luck on the CrossRoads project. That would be a real boon to Linux.

As for generics, yes, these are missing in C. It would probably make sense adding them to C, if the language was not completely ossified by now. There are macros though, which are somewhat less convenient to use, but more powerful at the same time.

or you can use bool init_foo() directly

If you really want term,use it and keep the destructor empty.
f->term();
delete f;

If you really want Bar to inherit Foo,you can do it like this
class Foo
{
public:
virtual bool init();
};
class Bar:public Foo
{
public:
virtual bool init()
{
Foo::init();
}
};

think of this requirement in c,
struct Foo
{
};
struct Bar
{
Foo base;
};

bool init_bar(Bar* bar)
{
init_fool(&base->base);
}

If c++ doesn't make things easier here,it doesn't make things harder.

Exceptions are idiomatic C++, and it is somewhat a "standard" way of handling constructor failures. It you choose not to use the exception feature, limiting yourself to a subset of C++, having to use workarounds/two-phase construction is the price to pay :(

I think the point of this article is not that C somehow allows you to do what C++ can't. That's nonsense, as C++ is superset of C. It's rather that when writing system-level code in C++ you often spend quite a lot of effort fighting the C++ features. The workarounds and non-idiomatic constructs also make code less readable.

Idiomatic C returns error code and you are expected to handle it immediately. To propagate it up the stack you have to do extra work (if (error) return another_error;).

Idiomatic C++ throws an exception and propagate it up the stack automatically. You have to do extra work not to propagate it (catch (…) {…}).

In other words, C encourages you to handle errors locally, while C++ encourages you to handle errors on higher level.

 // C++ version foo theFoo; // into state A theFoo.init(); // into state B theFoo.term(); // into state C // C version struct foo *theFoo; // into state A foo_init(theFoo); // into state B foo_term(theFoo); // into state C 

They are actually the same.

• State A: You can call the `init` interface only, which gets you to State B.
• State B: Fully functional. Calling `term` interface gets you to State C.
• State C: Leave it alone. Calling `init` gets you to State B.

The point of the state test in `foo::~foo()` is to check whether you called `foo::init()` and `foo::term()` before. You can/did not do that automaticly in the C version. If you want to achieve the same function, a state machine is also needed.

For inheritance in this "two step construction" style, the initialization of parent class is like a normal member object. There is no need to combine the states.

In the `if (rc != 0) handle_error();` example, since we are writing C++ equivalents, `fx()` should throw exceptions instead of error code too.

 try { fx(); } catch (std::exception& e) { handle_exception(); } 

As for the `if … handle; if … handle;` example: Why throw exceptions? C++ does not force you to throw exceptions. If you can test for `condition1` and you are determined to handle this condition, then handling it right there is a better choice.

 int rc = fx(); if (rc != 0) throw std::exception(); 

This code does not handle the exception, so it is not equivalent to

 int rc = fx(); if (rc != 0) handle_error(); 

Instead, it is equivalent to

 int rc = fx(); if (rc != 0) return generate_another_error_code(rc); 

So, you have no idea of who and where is going to handle the error either.

 class exception1 {}; class exception2 {}; try { ... if (condition1) throw my_exception1 (); ... if (condition2) throw my_exception2 (); ... } catch (my_exception1 &e) { handle_exception1 (); } catch (my_exception2 &e) { handle_exception2 (); } 

The above piece of code is not equivalent to this either:

 ... if (condition1) handle_exception1 (); ... if (condition2) handle_exception2 (); ... 

The C equilvalent should be something like:

 int foo() { ... if (condition1) return ERROR_CODE_1; if (condition2) return ERROR_CODE_2; ... } switch (foo()) { case ERROR_CODE_1: handle_exception1(); break; case ERROR_CODE_2: handle_exception2(); break; default: assert(0); } 

 int myclass_init (struct myclass *self) { ... } 

How is the solution with private constructor and a construct method and handling of exceptions simpler than that?

class XYZ {
private:
XYZ();
public:
static XYZ construct(int& error_code);
};

You just do the exception handing in one place (the construct method), and never have to worry about it again. Obviously you'd have to treat copying and assignment in a similar fashion, but that's no different in C. This does make constructing objects slightly more awkward than it would normally be in C++, but not really more than it is in C.

rc = fx ();
if (rc == 0)
do_something();
else if (rc == EINVAL)
do_something_else ();
else
assert (0);

You handle only the errors you are aware of (check the documentation of fx function). Everything else is considered a fatal error. Note that exceptions work in a similar way — unhandled exception causes program to abort.

to me, it has nothing different with adding a new type of exception in c++.

As for C, I've already re-written ZeroMQ in C (see nanomsg project) and the code is simpler, more readable, behaviour is fully defined etc.

Exceptions are just big returns. And the catch block is the call point.

You should have ONE exception class in your project, subclassed from std::exception. In that class you have members that hold the OS error code, an application specific error code, and a string that describes the error and possibly the file and line where the exception was thrown.

At the catch point you can decide how to handle the problem. In 95% of these things all you need to do is keep running, possibly logging a warning or error.

If you are down on exception syntax create a macro

#define IFTHROW(CODE) try { CODE } catch

That will act just like an old fashioned "if (err no)"

If you think C++ causes undefined behavior, just wait until you use C.

I don't remember the last time I used exceptions without scope_guard, but I remember the pain, which is pretty similar to what you describe.

IMO this problem is not new, its 10-15 years old, lots of solutions to this problem exists. scope_guards + lambdas make the code better than in C. std::optional makes the code _WAY_ better than in C. There are other idioms like Expected<T>. So instead of complaining that old style c++ exceptions are a pain you should move to new-style exception handling.

The problem with exponential code growth that you describe has nothing to do with c++ at all. It basically means that your hierarchy of exception classes is wrong. Instead of adding new catch classes to handle different exceptions types in the same manner, you should have fixed your exception class hierarchy. If you really do need to handle the exception differently, then yes, you need the extra code, and that code will be there if you translate your program to C.

However, exceptions are still bad because of decoupling the error and the error handler, as described in the article.

If I was designing a new language I would go for error codes and made it mandatory to handle them.

I have done mostly C++ for the last 12 years. Focus were on safety-critical software. I must say that I have almost never used exceptions. They are pretty much banned in safety-critical and real-time systems.

In fact the error handling you say is the "C" way of handling errors is to me just one way to handle errors. Which in fact is the real power of C++ to me. That you can choose different programming styles and paradigms.

Interesting read! I would not make the same conclusion myself as you did but either way I truly enjoy ZeroMQ and think it is an amazing library.

Cheers
Kjell

I agree that return codes are beter than exceptions most of the time, but thing they require some syntactic sugar in the language to remove the tons of extra boiler plate code that results where every function call has to check the previous one succeed before making the call.

I strongly disagree about init and cleanup methods, they are never a good idea, all objects should be valid and meet their invariants after construction, period. If you don't want exceptions but do want constructors to be able to fail then either use a static factory methods or the builder pattern. Both solve the same problem, verifying the preconditions of your constructor are met and only returning a valid object. One does tries and asks for givenness and the other ensures it will work then only tries once it knows (both use a

// using char and raw pointers to keep example as simple as possible
class Foo {
Foo(const char * inFile, const char * outFile) {
// could fail but will only throw FooException
}

public:
static Foo * create(const char * inFile, const char * outFile) {
try {
new Foo(inFile, outFile);
} catch (FooException &) {
// handle exception here
// this is the only place where exceptions are thrown or caught
return 0;
}
}
}

or with builder

FooBuilder fb = FooBuilder().inFileParam("some path).outFileParam("some other path");
if (fb.canBuild()) {
Foo * = fb.build();
}

Regarding destructors and exceptions i feel if there is a chance you could throw in a destructor the class is probably doing to much, part of the class' state belongs in a function.

Scala has introduced a nice why to handle exceptions with there scala.util.Try<T> class, this is a generic type that holds a value or an exception. So any function that can fail returns a Try<T>. the exception holds any information that might be required about what happened. If you use closures the Try can provide two methods so safely deal call functions on your code.

template <typename T>
Class Try {
boolean hasValue();
boolean hasException()

template <typename R>
Try<R> map(std::function<R(T)>); // For functions that don't fail

template <typename R>
Try<R> flatMap(std::function<Try<R>(T)>); // For functions that could fail
};

Try<string> hostaddress = …
Try<Socket> socket = hostaddress.flatMap(resolveAddress);