This is actually a quite old idea. Here's a comp.lang.c++.moderated thread from 2000 discussing the idea:

https://groups.google.com/group/comp.lang.c++.moderated/brow...

The OP there did not pass an extra parameter, but used the return value itself to deliver the exploding return code.

I've used this from time to time as a debugging aid, because it allows me to track down places in my code where I forget error checks. Using the exploding codes in live code is not a good idea however, because they rely on throwing in destructors, which is a bad thing to do.

This is interesting, but given the relative failure of the checked exceptions experiment in Java, it seems unlikely to catch on.

This is similar to the GError concept used in glib, the C utility library underpinning the GTK+ UI framework.

API documentation: http://library.gnome.org/devel/glib/stable/glib-Error-Report....

Of course, glib being C it cannot provide the same level of checking that C++ can do, so it's quite basic, but also quite nice to work with.

I'm having flashbacks to the nineties and working with CORBA and it's C bindings.

"Those who do not know history are doomed to reinvent CORBA_Environment."

(Although there are few new details, such as the aborting if the dtor determines it wasn't checked.)

A better approach for this that I use in my personal applications is to combine the concept of an error code and a result into a single object that records the 'checked' state. Attempting to fetch a value from one of these result objects will throw if the result object contains an error, which handles the common case, and the less common case - forgetting to check at all - can explode violently as described here. If you want to simply discard the error code or handle it manually, you can just check the failure status of a result object and go about your merry way. It's a nice compromise and it happens to integrate nicely if you're already using futures/promises to represent work.

This is what the Maybe monad is for :-)

Or the `Either` monad, or union types/ADT in general, `Maybe` is just a pretty basic application of those.

So every function I write has to take an extra parameter? No thanks.

Like a comment on the article says, this is Java checked exceptions for C++.

Checked exceptions don't give you exception safety for free: they give you boilerplate code, and exception safety is still up to the developer.

(I never bought the argument about exceptions obfuscating control flow, either.)