🚀 go-pugleaf

sakkinen@jyu.fi (Markku Sakkinen) writes:

>fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
>> ...
>>Actually, in C++ I would write
>>   struct excp1 : Exception {};
>>		^^^^^^^^^^^
>
>What would that buy you?  See below.
>
>>>Inheritance between exceptions may be treacherous, since 'throw'
>>>does not work "virtually".  E.g., with Fergus's example:
>>> ...
>> ...
>>You can make throw behave virtually by throwing a pointer to the exception
>>instead of the exception itself:
>
>(Or a reference.)  Yes, I must admit that this problem is not very severe.

You can't throw a reference.
	
	Exception value;
	Exception& reference = value;
	throw reference;

This will throw the value refered to by the reference, not the reference
itself.  [Well, this is what I infer from reading the RM] 

>>	throw new SomeException(...)
>>although you need to take care to ensure that the storage is correctly
>>deallocated by the handler, to avoid memory leaks.
>
>The example is not the best possible one, since here the exact type
>of the referenced object is in fact statically known.
>The handler has no way to know when it has to delete the exception object,
>short of there being a quasi-Boolean field 'delete_me' in Exception.
>Thus:
>
>struct Exception { int delete_me; };
>throw new Exception (1);
	This throws an (Exception *)
>Exception ex (0);
>throw ex;
	This just throws an Exception.
	So you can distinguish between them by

	try ...
	catch(Exception *e_ptr) {
		...
		delete e_ptr;
	}
	catch(Exception& e) {
		...
	}

>And now to a perhaps better reason why using inheritance with exceptions
>(as suggested by you above) may be treacherous.
>Whenever there exists a handler for _any_ ancestor (base class) of the
>class of the exception object, that handler will be happily executed.
>Thus, if an instance of a class derived from Exception is thrown,
>there is no guarantee that any more specific handler than that
>of Exception will be invoked.
>This is essentially different from virtual functions, with which it is
>guaranteed that dynamic binding will find the function appropriate
>for the true class of the 'this' object.

Actually, this is just a reason to always catch exceptions by reference.
Then the handler can call virtual functions in the exception object.

Raising an exception is then equivalent to passing an object to a function
that takes a reference parameter. Of course, in both cases you can't
*guarantee* that the exception handler / receiving function will actually
call any virtual functions, but you know that if it does then the behaviour
will be appropriately polymorphic.

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature virus is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!