[Corelinux-public] Exceptions Feedback

[Frank V. C. <fr...@co...>]

The past few days have brought e-mails to me from people who are on the
outside of the mailing list. I have directed them to it, but until then
I want to summarize some of the things brought up:

1. Exception specification - Will we include the @exception tag in the
class declaration comments? What strategy is going to be defined for
exception types? 

To the first part, from a documentation standpoint, when I declare a
method and I know it has the potential for a specific assertion
(invarient checkes, assert check, etc) I usually include it in the
signature, as an example:

	/** 
	Set something
	@param SomeArgument [const reference | pointer | whatever ]
	*/

void	setSomething( SomeArugment ) throw(Exception); // or
void	setSomething( SomeArgument) throw(Assertion);

Doc++ will create hyperlinks back to Exception or Assertion because they
are part of the class documentation. Within CoreLinux++ declarations it
is reasonable to omit the @exception tag in this case, it is done for
us. But, this does not help with generation tools that we don't know if
they automatically infer the link from the signature. I believe ( and as
always it is my opinion only ) the safe way to go is to ALSO include the
@exception tag even though it is clear in the declaration.

To the second part, the author and I exchanged e-mails along the likes
of exception type specification. In other words, the generic exception
can not be reasoned with other than to use default behavior. So, the
point being that:

--------------------------------------------------------

class Bridge : public CoreLinuxObject
{
public:
	// ...

	BridgeRef  operator=(BridgeCref) throw(Exception);
};

--------------------------------------------------------

//
// can't be reasoned with compared to:
//

--------------------------------------------------------

class BridgeException : public Exception {..};

class Bridge : public CoreLinuxObject
{
public:
	// ...

	BridgeRef  operator=(BridgeCref) throw(BridgeException);
};
--------------------------------------------------------

//
// at a minimum, and
//

--------------------------------------------------------

class BridgeException : public Exception {..};
class SetImplementationException : public BridgeException {..};

class Bridge : public CoreLinuxObject
{
public:
	// ...

	BridgeRef  operator=(BridgeCref) throw(SetImplementationException);
};

--------------------------------------------------------

being more useful.

I believe that we SHOULD have an Exception type for each class, and it
would probably be a good idea to have a type hierarchy where applicable.
The user, when extending our classes to their domain, could continue the
extension accordingly.

A recent experience of mine has been that, in addition to Exception
Types, we had an Exception ID (Dword) that addressed two (2)
requirements; 1-The id was useful as a key for faulting in an
internationalized text message, and, 2-Kept the implementation down to a
more generic level although you still could reason with the Exception
ID. 

So:

--------------------------------------------------------

try
{
   ...
}
catch( ExceptionRef aRef )
{
   switch( aRef.getIdentifier() )
   {
      case handled0:
         break;
      case handledN:
         break;
      default:
         throw; // rethrow unhandled
   }
}
catch( ... )
{
   ...
}

--------------------------------------------------------

//
// versus 

--------------------------------------------------------

try
{
   ...
}
catch( SetImplementationExceptionRef aRef )
{
   ...
}
catch( BridgeExceptionRef aRef )
{
   ...
}
catch( ExceptionRef aRef )
{
   ...
}
catch( ... )
{
   ...
}

--------------------------------------------------------

Potentially produce the same results in regards to coverage, the latter
filling in the domain extension need. On the otherhand, the former has
many assumptions at our class library level and is difficult to extend
Exception IDs to new domains.

Anyone?

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux