Re: C++0x/1x exception specifications proposal: Compile-time checked

On Tue, 2008-01-22 at 05:22 -0600, Francis Glassborow wrote:


???I think (from using Java, suffering problem 2 below, and Haskell, not
suffering problem 1 below in some cases and irritatingly suffering it in
others) the two big problems with statically checked exception
specifications are:

   1) The typing limitations of C++ (eg, vector::begin() and
vector::end() on a vector of size > 0 have the same type even though one
can be incremented and dereferenced and the other can't) and,
   2) the runtime polymorphism of OOP which allows (sensibly) additional
exceptions to be thrown by methods of derived classes. This means that
the caller knows the exact type and thus wants to be told of the
specific exception, having knowledge of the extended list of receivable
exceptions, yet the callee knows nothing of the additional exceptions
and to be useful *must* forward them on.

???1 is a problem for generic programming and perhaps Concepts could be
used to enhance exception specifications in this context somewhat
similarly to my solution to 2, if my solution to 2 doesn't also work for
that case immediately.

2 could perhaps be solved with a type set algebra for/in exception
specifications, something like:

class MyClass {
public:
   virtual throw io_exceptions = block_error | char_error; // union

   virtual void writesomething(unsigned char* data, size_t size)
     throw(io_exceptions) = 0; // callers know to pass on additional
   // exceptions because the exception spec is a "virtual" set
};

class MyNetworkClass : public MyClass {
   throw io_exceptions = MyClass::io_exceptions | network_error; // union
   // can be extended because it's a virtual throwset definition

   void writesomething(unsigned char* data, size_t size)
     throw io_exceptions { ... defn ... }
};

void fn(MyClass&& obj) throw(obj.io_exceptions | bad_alloc)
                    // caller and "fn" each evaluate the exception
                    // specification in the context of their
                    // respective knowledge
                    // eg, "fn" knows to support forwarding
                    // of unknown exceptions because
                    // obj.io_exceptions is virtual
{
.... defn ...
}

where a function just passes the object reference along to another
function, it could reference the exception specification of the function
that it calls (or a common named throwset defintion)

Since throw is never used in class definition context and the existence
of this use could be used to switch static typechecking on for callers
of methods of that class and its subclasses, as well as callers of
functions that use that classes name, also using the set algebra in a
throw specification (as above) would make callers use strict checking.
Thus preserving behaviour of existing programs and doing the expected
thing when using static checked code with old code in the same program.

--
Tristan Wibberley

Any opinion expressed is mine (or else I'm playing devils advocate for
the sake of a good argument). My employer had nothing to do with this
communication.

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated. First time posters: Do this! ]