3 ms·

Exploding Error Codes (C++)

22 points by pmjordan 16y ago

Jabbles 16y ago
So every function I write has to take an extra parameter? No thanks.
- timrobinson 16y ago
  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.)
Robin_Message 16y ago
This is interesting, but given the relative failure of the checked exceptions experiment in Java, it seems unlikely to catch on.
unwind 16y ago
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-Reporting.html 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.
kevingadd 16y ago
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 16y ago
  This is what the Maybe monad is for :-)
  - masklinn 16y ago
    Or the `Either` monad, or union types/ADT in general, `Maybe` is just a pretty basic application of those.
odradek 16y ago
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/browse_thread/thread/6466a3dfa2adf2b/d3b6d29cadfcc145?hl=de&ie=UTF-8&q=exploding+return+codes+c%2B%2B&pli=1#d3b6d29cadfcc145 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.
eskil 16y ago
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.)

22 points by pmjordan 16y ago

Jabbles 16y ago

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

timrobinson 16y ago
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.)

Robin_Message 16y ago

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

unwind 16y ago

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-Reporting.html 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.

kevingadd 16y ago

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 16y ago
This is what the Maybe monad is for :-)
- masklinn 16y ago
  Or the `Either` monad, or union types/ADT in general, `Maybe` is just a pretty basic application of those.

odradek 16y ago

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/browse_thread/thread/6466a3dfa2adf2b/d3b6d29cadfcc145?hl=de&ie=UTF-8&q=exploding+return+codes+c%2B%2B&pli=1#d3b6d29cadfcc145 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.

eskil 16y ago

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