In article <9j6hk0ppqjpisak9pepv5cq5t09ad8nfac@4ax.com>, Toaster says...
>
>On Wed, 15 Sep 2004 18:57:31 +0000 (UTC), Sean Kelly <sean@f4.ca>
>wrote:
>
>>Why allow the destruction of a connection object to invalidate all query objects open through that connection?  I would be more inclined to do something like this:
>
>I don't do that. You can invalidate any query (bottom) object without
>invalidating the connection (middle) object.
>
>To be specific, if a connection object's destructor is called, it first disconnect()s from the data source, then it frees the hdbc.
>
>If I don't finish and free the hstmt's prior to that, the disconnect() may or may not be sucessful; if not the hdbc stays connected even after destruction of it's container object, probably forever until the program exits.
>
>But by disconnecting and freeing the hdbc, all derived hstmt handles become invalid. Now, if the gc destructs the connection object first, then the result object, the result object's hstmt will have been invalidated by the API - access violation. This can't happen if I delete all result objects prior, getting all hstmt freed, and free the hdbc then. I think it's appropriate to do so, I just copy the behaviour of the API to the classes: closing a connection renders all statements useless.

What I was suggesting was just to have the connection handle managed separately from the connection object itself.  Though I suppose these are different approaches.  You want any statements using a connection to be closed and (I assume) exist as skeletons if the connection is closed--perhaps throwing a ConnectionClosed exception if the user tries to manipulate the statement--while I want the connection to remain open so long as there are any statements using it, whether or not the connection object hsa been deleted.  I'm not sure that either is any more correct than the other, though I know which I prefer :)


Sean

On Wed, 15 Sep 2004 21:10:48 +0000 (UTC), Sean Kelly <sean@f4.ca>
wrote:

>What I was suggesting was just to have the connection handle managed separately from the connection object itself.  Though I suppose these are different approaches.  You want any statements using a connection to be closed and (I assume) exist as skeletons if the connection is closed--perhaps throwing a ConnectionClosed exception if the user tries to manipulate the statement--while I want the connection to remain open so long as there are any statements using it, whether or not the connection object hsa been deleted.  I'm not sure that either is any more correct than the other, though I know which I prefer :)
>
>
>Sean
>

This would be another way, but it's not what I want.
Whenever the code closes a connection or frees an environment, I want
all depending objects to  disappear. So the user doesn't have to
figure out why his broken object doesn't work - there IS no broken
object, just an invalid reference, it's that simple. I think the user
can check for that in D, and what I have seen from my own bugs is that
D returns the access violation in an exception.

Anyway,in this case  this is not a runtime error in a finished application, usually this is an implementation error and no checking should be necessary in the debugged final code.

So you don't have to implement in each and every method of the object the "if the connection is closed then don't call the API, throw an exception instead". And the user doesn't call any bottom.isTheParentStillAlive() functions, he just does assert(bottom); that's all.