|Subject||RE: [IB-Architect] New API: Exceptions|
|Author||Claudio Valderrama C.|
> -----Original Message-----I raised an exception, sir! <grin>
> 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
of why pointers to SQLException
> objects were thown (and caught) rather than the objects themselves.Is there any compelling reason to not being able to use
> The difference in the handler is:
> catch (SQLException exception)
> 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).
catch (SQLException &exception)
> Here is the answer: If we want to declare SQLException as anOr the reference form.
> abstract class (as opposed the specifying the implementation
> as part of the API), we have to use the pointer form.
> The firstTrue, although I suspect MSVC++ will compile happily.
> example above is not legal C++: An abstract class cannot be
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 --It's the closest we can be to an "interface" in C++.
> no inherited code. I think the pointer form is the way to go.
> Which brings us to the question exception object life time. WeIf we think a bit, a class can be viewed as an object, but at some point 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
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.