> -----Original Message-----
> From: Jim Starkey [mailto:jas@...]
> Sent: Jueves 1 de Junio de 2000 16:52
> To: IB-Architect@egroups.com
> Subject: [IB-Architect] New API: Exceptions
>
> Claudio had raised the question

I raised an exception, sir! <grin>


of why pointers to SQLException

> objects were thown (and caught) rather than the objects themselves.
> The difference in the handler is:
>
> catch (SQLException exception)
> {
> ...
> }
>
> and
>
> catch (SQLException *exception)
> {
> ...
> delete exception;
> }
>
> As he pointed the, a problem with throwing a pointer is that
> somebody has to delete the throw object or suffer a memory leak
> (more about this later).

Is there any compelling reason to not being able to use

catch (SQLException &exception)

for example?

> Here is the answer: If we want to declare SQLException as an
> abstract class (as opposed the specifying the implementation
> as part of the API), we have to use the pointer form.

Or the reference form.

> The first
> example above is not legal C++: An abstract class cannot be
> instantiated.

True, although I suspect MSVC++ will compile happily.
;-)

Personally, I don't like the idea of copy constructors for exceptions, but
this is just me.

> I think there great merit in defining the API as pure interface --
> no inherited code. I think the pointer form is the way to go.

It's the closest we can be to an "interface" in C++.

> Which brings us to the question exception object life time. We
> could say that an implementation controls the object life (like
> next what?). Or we bite the bullet and use the same general
> mechanism as other user visible object -- addRef/release. See
> next post.
>
> Jim Starkey

If we think a bit, a class can be viewed as an object, but at some point we
should cut the chain. An exception is an object (although I can raise an
integer if I'm enough mad) but I would let such exception to be cleaned by
the normal exception mechanism, if possible.

C.