A Tour of Rare C++ Features Part 2: Function Try Blocks, Catch-All Exception Handlers and Rethrowing

In the previous installment  of this series we explored the combined use of trailing return types, decltype and multicharacter literals that together explain why the following snippet actually contains a correct main function:

 1/* This is valid C++ */
 2auto main() -> decltype('O.o') try
 3<%[O_O = 0b0]<%
 4https://daniel.schemmel.net/post/2015/a-tour-of-rare-c++-features-part-1
 5typedef struct o O;
 6o*(*((&&o(o*o))<:'o':>))(o*o);
 7if(O*O = decltype(0'0[o(0)](0))(0)) 1,000.00;
 8else return 0==O==0 ? throw O_O : O_O;
 9%>();%>
10catch(...) { throw; }

This time, we are going to explore how the body of this function can be correct. When declaring a function, its prototype (ending in this case in line 2 with decltype('O.o')) is terminated with a semicolon. On the other hand, when defining a function, the next token is usually an opening curly brace: {. So what is happening here?

As the title of this post already hints, this is a so-called function try block. Instead of starting a normal compound-statement, also known as block, which is the technical term for "a list of statements surrounded by curly braces", a function definition may instead be given by a try block followed by one or more exception handlers (catch blocks).

While there are some special rules with respect to scope and suppressing thrown exceptions in some cases, which will be explored later, a function try block mostly behaves just as a normal function which only contains the try/catch construct as its only statement.

That means the following two functions behave the same:

 1void f() {
 2    try {
 3        throw 4;
 4    } catch(int) {
 5        return;
 6    }
 7}
 8
 9void g() try {
10    throw 4;
11} catch(int) {
12    return;
13}

Catch-All Exception Handlers

The last line of the example contains an exception handler with an ellipsis instead of an argument. This syntax is used if one wants to catch any and all exceptions. Obviously, one cannot refer to the actual exception anymore, as it has unknown type¹.

Of course this makes it hard to deal with the exception, but four important options are still available:

1. We can perform cleanup code that is independent of exactly how the code failed. After all, it is not important why we need to close a file we may have opened previously, just that it be closed correctly.
2. We can suppress the exception. In some cases we know that an exception may be thrown without really caring about the type of the exception. This is very dangerous, as it will also suppress exceptions like ::std::bad_alloc , which is thrown when ::operator new  fails.
3. We can throw our own kind of exception instead (although it cannot wrap the inner exception, as it cannot access it). This allows us to write interfaces whose possible exceptions are known that still reuse code we may not really be sure about.
4. We can perform some kind of cleanup, logging or other operation and then rethrow the exception. This is exactly what happens in the example and is discussed at length in the next part of this post.

Rethrowing Exceptions

In the example, there is a throw statement without anything to throw. This is how exceptions are correctly rethrown from inside an exception handler. Consider the following fragment², where a file is opened, after which an operation is performed that may throw. Obviously we need to close the file either way.

1FILE* a = ::std::fopen("cake.txt", "r");
2try {
3    eat(a);
4} catch(::std::exception& e) {
5    ::std::fclose(a);
6    throw e;
7}
8::std::fclose(a);

Now, this code has three major problems: First, it assumes that eat will only ever throw exceptions that are derived from ::std::exception. Second, the stack trace that a debugger will show may very well show the throw in line 6 as the culprit that threw the exception. Finally, it changes the static type of the exception  meaning it will now be considered a ::std::exception for the purpose of catching it, no matter what its type was when it was originally thrown.

All of these problems can be dealt with by rewriting the code to use a catch-all exception handler with a rethrow - we do not need to know the exception to rethrow it:

1FILE* a = ::std::fopen("cake.txt", "r");
2try {
3    eat(a);
4} catch(...) {
5    ::std::fclose(a);
6    throw;
7}
8::std::fclose(a);

What are function try blocks useful for?

So, if a function try block behave the same as if it would be wrapped in curly braces, why do they exist? Is this only a quirk of the C++ syntax requiring two characters less to type in a fairly rare case? Of course³ not, but their use is fairly restricted and intended for a very specific case.

Please consider the following piece of code:

 1struct A {
 2    A() { throw "cake"; }
 3};
 4
 5struct B : A {
 6    B() : A() {
 7        try {
 8            // initialize B some more
 9        } catch(char const* reason) {
10            ::std::cout << "Could not initialize B: " << reason << "\n";
11            throw;
12        }
13    }
14};

Here the constructor of B will also call the constructor of A. The idea is that an error during construction of B should be caught in the catch block and be logged to the console before being rethrown⁴.

However, the constructor of A is not performed inside the try block and its exception will therefore never be caught! This is shown by the explicit initialization of A in line 6, but would also happen if A where to be initialized implicitly instead. As you may have guessed, this problem can be solved by virtue of a function try block:

 1struct A {
 2    A() { throw "cake"; }
 3};
 4
 5struct B : A {
 6    B() try : A() {
 7        // initialize B some more
 8    } catch(char const* reason) {
 9        ::std::cout << "Could not initialize B: " << reason << "\n";
10        throw;
11    }
12};

Now, the initialization of A is performed inside the try block! If you compare the previous version  to the new version using function try blocks , you will notice that both programs still crash (after all, we rethrow the exception), but the new version will perform the cleanup code in the exception handler.

Function try blocks have been around since the very first version of the C++ standard: ISO/IEC 14882:1998, although the wording has been changed  with C++11.

Gimme more!

This post is part 2 of a series on rarely used C++ features. Continue to the next part, Part 3 .