In other words a fixture is expected to be implemented as a class where
the class constructor serves as a setup
method and class destructor serves as teardown
method. The Unit Test Framework opted to avoid explicit
names in fixture interface for setup
and teardown methods, since
it is considered most natural in C++ for tasks similar to RAII and coincides
with the pure C++ solution discussed above.

The above interface prevents you from reporting errors in the teardown procedure using an exception.
It does make sense though: if somehow more than one fixture is assigned
to a test unit (e.g. using fixture decorator), you want
all teardown procedures
to run, even if some may experience problems.