
Exploding Error Codes (C++) - pmjordan
http://engvhack.blogspot.com/2009/11/exploding-error-codes.html
======
odradek
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...](https://groups.google.com/group/comp.lang.c++.moderated/browse_thread/thread/6466a3dfa2adf2b/d3b6d29cadfcc145?hl=de&ie=UTF-8&q=exploding+return+codes+c%2B%2B&pli=1#d3b6d29cadfcc145)

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.

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

------
unwind
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...](http://library.gnome.org/devel/glib/stable/glib-Error-
Reporting.html).

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.

------
eskil
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.)

------
kevingadd
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.

~~~
gaius
This is what the Maybe monad is for :-)

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

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

~~~
timrobinson
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.)

