Bill Lancaster <yolo@...> wrote:

>>Claudio had raised the question 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).
>
>
>I believe Glebas was correct with
>
>catch (SQLException &exception)
>{
>}
>
>except I would add a const before SQLException. SQLException is an
>abstract base class.
>
>>case 1 above, a copy constructor would be necessary to copy
>>an implementation specific subclass of SQLException to SQLException
>>itself, which more or less eliminates any added value an implementation
>>extension might provide. It would also make extensions of the API
>>difficult and dangerous.
>
>I'm not sure what you're saying but I "think" being responsible for
>deleting a pointer is dangerous and unnecessary. In most situations you
>should ALWAYS have a copy constructor, destructor, and assignment operator
>or you'll get one that you don't know about.

There are more problems with being required to call delete on a pointer
caught in an exception handler.

- The delete operator might not match the new operator: For example,
overloaded operators and alternative heaps (eg. across DLL boundaries with
per DLL runtime libraries). If a pointer is to be thrown, it should follow
the addRef()/release() protocol using virtual methods to avoid these
problems.
- Memory leaks, as has been pointed out:

try { a bunch of stuff } catch(...) { cerr << "something broke" << endl; }
// memory has leaked.

Besides, defining an exception class shouldn't be so painful. What are the
problems you (Jim) are trying to avoid?

(There has been other interesting stuff in this and other threads. I'll try
to read and reply some of it later today).

Jan Mikkelsen