🚀 go-pugleaf

In article <9227620.2176@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
>sakkinen@jyu.fi (Markku Sakkinen) writes:
>> ...
>I guess it is true that programmers just don't like verbosity.
>OK, here is the succinctness-at-all-costs solution:
>
>	#define e(x) class x : Exception {} ;
>	e(e1)  e(e2)  e(e3)  e(e4)  e(e5)  e(e6)  e(e7)  e(e8)  e(e9)  e(e10)
>	e(e11) e(e12) e(e13) e(e14) e(e15) e(e16) e(e17) e(e18) e(e19) e(e20)
>
>Is that short enough, or should I remove all the unnecessary whitespace? ;-)

Not being a C or C++ fan, I don't like succinctness at all costs.
In this case, I like succinctness without cost a la Ada.

> ...
>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.

>	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);
Exception ex (0);
throw ex;

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.

----------------------------------------------------------------------
Markku Sakkinen (sakkinen@jytko.jyu.fi)
       SAKKINEN@FINJYU.bitnet (alternative network address)
Department of Computer Science and Information Systems
University of Jyvaskyla (a's with umlauts)
PL 35
SF-40351 Jyvaskyla (umlauts again)
Finland
----------------------------------------------------------------------