Re: Why do some code bases don't use exceptions?

From:

"Alf P. Steinbach" <alfps@start.no>

Newsgroups:

comp.lang.c++

Date:

Thu, 26 Nov 2009 03:26:43 +0100

Message-ID:

<hekotb$v8d$1@news.eternal-september.org>

* Richard:

[Please do not mail me a copy of your followup]

"Alf P. Steinbach" <alfps@start.no> spake the secret code
<hekgtv$un9$1@news.eternal-september.org> thusly:

* Richard:

[Please do not mail me a copy of your followup]

"Alf P. Steinbach" <alfps@start.no> spake the secret code
<hejsud$83s$1@news.eternal-september.org> thusly:

* James Kanze:

Yes, but having to write a try block, then a catch statement, is
more complicated than an if, if you want to process the error
immediately. You can use an exception, but it's about like
pealing a grape with a butcher's cleaver.

Off the cuff,

#define CATCHX( result, f, args ) \
    do { \
        try { \
            result = f args; \
        } catch( std::exception const& x ) { \
            result.set_x( x ); \
        } \
    } while( false )

....which is a good example of why macros are evil.

Mostly macros are evil, but your comment for this case makes no sense to me.

Would you care to elaborate a bit on exactly what you mean (if anything).

Macros hiding loops, returns or try/catch blocks are evil IMO.

OK.

Then observe:

   * The macro doesn't hide a try-catch block. Its name makes it abundantly
     clear that it catches an exception.

   * The macro doesn't contain a return.

   * The macro doesn't contain a loop. Or well, there is what might look like
     a loop, but it's just an old well-known syntactical device, to make the
     macro invocation function-like wrt. C++ semicolon rules, especially in
     if-else constructions.If you're unfamiliar with this then you've learned
     something new! :-)

So, none of your evilness indicators are present.

Cheers & hth.,

- Alf

PS: By the way, much of this macro stuff will be unnecessary in C++0x, which
much better supports argument forwarding.