🚀 go-pugleaf

This came up in the context of arguing that explicit dynamic type
checking is sometimes needed. In a previous posting I described three
cases where such dynamic type checks were indispensible :), the third
being exception handling.

Come to think of it, as I understand it:

	The C++ exception handling scheme REQUIRES a limited form
	of dynamic type checking, including identifying derived classes.
	Objects may NOT need access to their types, but type-IDs are
	needed by the run-time system, and checks of the sort:
	"is class X derived from class Y" are needed at run-time.

Do I understand this correctly ?

rae@utcs.toronto.edu (Reid Ellis) writes:

  >   Desmond Dsouza <dsouza@optima.cad.mcc.com> writes:
  >   >Consider the proposed (now accepted) Exception Handling scheme for
  >   >C++. The statement:
  >   >  catch (ErrorClass& o) {
  >   >	....
  >   >  }
  >   >is supposed to 'catch' a deeply nested call to:
  >   >  throw ErrorClass("someError");
  >   >
  >   >Any implementation of this involves a run-time type check, including
  >   >class derivation, on the object being thrown. Can you say 'Meta-class'?
  >
  >   This is simply overloading based on argument type.  Just like having
  >   methods named "foo(Tbase &)" and "foo(Tderived &)".  No "Meta-class"
  >   required.
  >
  >					   Reid
  >   --

Sorry, but it is *not* simply static overloading. The exception  model is:

	- you CATCH a CLASS of objects (including derived class instances)
	- you THROW an OBJECT ( whose class is known statically ?? )

The run-time exception handler searches the stack for the first catch
(handler) which can handle the object you are throwing and transfers
control there.

Consider:

--------------------------------------------------
class File_Error {  .... };
class No_Access : public File_Error { ... };

main (){

  try {
	read_in_file ("non_existent_file");	// [1]
      }

  catch (File_Error fe) {			// [2]
	...
      }

}

...
...

read_in_file (char* file) {
   if (cannot_access_file (file))
	throw ( No_Access (file));		// [3]
   ...
}
--------------------------------------------------

Line [2] establishes a handler for the *class* File_Error, and hence
for ALL classes derived from it.

Line [3] raises an exception, by creating and THROWing an *object* of 
class No_Access. This should transfer control to line [2]

The combined compile-time and run-time system MUST establish, at line
[3], that the thrown object is an instance of a class derived from
File_Error. 

  Is it true that that only the static type of the thrown
  object is used ? If so, what of pointers e.g. throw (new No_Access)? 
  If not, dont we need run-time access to the type of an object?

	ARM, p 356:
	A 'throw-expression' initializes a temporary of the static
	type of the operand of 'throw' and uses that temporary to
	initialize the appropriately typed variable named in the
	handler. 
 >

Thus, the compiler must encode into line [3] some representation of
the class No_Access and its base class, File_Error.  (It must also
encode into line [2] some representation of the class File_Error.)

Lets call this representation, just for the heck of it :), an
'object'. This 'object' needs to encode a class and its base classes,
at least by name, and needs to know something about initializations
(e.g. for variable 'fe' on line [2]).

The class of this 'object' thus has instances which themselves
represent (some aspects of) classes.

Can you say "meta-class" ?

(See Chapter 15 of the ARM for details, or Stroustrup's paper
"Exception Handling for C++ (revised), USENIX C++ Conf, April 1990)


--
Desmond D'Souza
--

-------------------------------------------------------------------------------
 Desmond D'Souza, MCC CAD Program | ARPA: dsouza@mcc.com | Phone: [512] 338-3324
 Box 200195, Austin, TX 78720 | UUCP: {uunet,harvard,gatech,pyramid}!cs.utexas.edu!milano!cadillac!dsouza