Calling DataAdapter.Update() on disposed DataSet?

  • Thread starter Thread starter Carlo Razzeto
  • Start date Start date
C

Carlo Razzeto

Hey,

Some one gave a new developer of ours a project to make sure our core
library funcitons are properly cleaning up resources (that's a good thing!),
but I had consernse about one thing the developer was doing which sparked a
debate with my co-worker.

Some of these functions were returning DataSet objects, and the developer
was calling the Dispose() function on the datasets inside the finally
portion of a try block. For me, this kind of raised a red flag, because it
seems to me the funciton is then returning an object which it has already
"cleaned up". In some cases an "end programmer" might even want to take this
dataset, modify datarow values and call a DataAdapter.Update() on it. It
just doesn't seem like a very safe practise to me.

Am I being overly cautious here? I guess I just have a problem with
returning "cleaned up" object in general, to me it seems like no good can
come from that. Thanks for your thoughts,

Carlo
 
Dispose should be called only when object isn't needed anymore.
In the case of DataSet, Dispose probably doesn't do anything and thus it
still works. However, this is a dangerous practice and should be avoided.
 
These are my feelings exactly, thank you so much for confirming. Even if it
works in this case I'm afraid someone will see this working and decide it
will make a great standard practice.


Miha Markic said:
Dispose should be called only when object isn't needed anymore.
In the case of DataSet, Dispose probably doesn't do anything and thus it
still works. However, this is a dangerous practice and should be avoided.
--
Miha Markic [MVP C#, INETA Country Leader for Slovenia]
RightHand .NET consulting & development www.rthand.com
Blog: http://cs.rthand.com/blogs/blog_with_righthand/

Carlo Razzeto said:
Hey,

Some one gave a new developer of ours a project to make sure our core
library funcitons are properly cleaning up resources (that's a good
thing!), but I had consernse about one thing the developer was doing
which sparked a debate with my co-worker.

Some of these functions were returning DataSet objects, and the developer
was calling the Dispose() function on the datasets inside the finally
portion of a try block. For me, this kind of raised a red flag, because
it seems to me the funciton is then returning an object which it has
already "cleaned up". In some cases an "end programmer" might even want
to take this dataset, modify datarow values and call a
DataAdapter.Update() on it. It just doesn't seem like a very safe
practise to me.

Am I being overly cautious here? I guess I just have a problem with
returning "cleaned up" object in general, to me it seems like no good can
come from that. Thanks for your thoughts,

Carlo
 
Excerpt for some exception, this is the right thing to do. The finally
portion of a try block has been called; this mean that an error occurred
earlier and that the object is now in an unknown, unstable or unsafe state
and should not be used anymore. Every object who has the IDispose interface
should be disposed of in the finally portion of a try block and the Dataset
object is no exception to this rule.

Of course, there are always some exceptions to any rule; for example when
you know that some portions of the object are still valid and that you want
to continue to operate on these portions but these are exceptions and you
should take some serious precautions when dealing with these.

In your case, the end programmer who might want to call the
DataAdapter.Update() is making an error because he's trying to operate on an
object for which there has been an error and therefore is in an unknown and
unstable state. Even if the Dispose() method would have not been called on
this object; trying to update the database through this object could lead to
some serious damages to the database; because essentially you are shooting
in the dark.
 
Ok, lol... After reading what you wrote I was going to have some questions,
just wondering if there was something I haddn't considered. This post tells
me that this isn't the case. :)

Carlo
 
Carlo,

AFAIK does the dispose of a DataSet nothing as long as there is a reference
to the DataSet or that the DataSet has a reference (which mostly is because
it has some tables).

I have tried this some years ago and I thought that it was the behaviour.

But there seems to be some maniaks who think that the dispose in .Net is the
same as deconstructing.

Cor
 
No, it's just surprising how fast you can forget some basic things about a
language when it has been some time since the last time you have used it
(and especially but not necessarily when you are doing something else like
waiting for something to finish).

Maybe I should stop trying to make two things at the same time but on the
other hand, a lot of potentially useful posts would be lost; so I suppose
that's probably better to make some basic error from time to time in favor
of the greater good.
 
Sylvain Lafontaine said:
Excerpt for some exception, this is the right thing to do. The finally
portion of a try block has been called; this mean that an error occurred
earlier and that the object is now in an unknown, unstable or unsafe state
and should not be used anymore.

Ehm, not exactly. finally block is always run regardless whether error
occured or not - that's why it is called finally.
If the error occurs (aka Exception is thrown) then except block is executed
first (here you know that exception occured, but the object might be in safe
state - depends on the various factors) and finally block after it.

Every object who has the IDispose interface
should be disposed of in the finally portion of a try block and the
Dataset object is no exception to this rule.

You have to dispose something only if you don't need it anymore. If you want
to return an object to a caller you won't dispose it, will you?
 
Yes, but still I just didn't see it as being particularly safe. While it may
be safe in the dataset, I'm just afraid that down the line some developer
will see this happening in our lower level library, think it's a great short
cut to skirt having to dispose of your objects properly (i.e. at the right
time) and start copying the behaviour with impunity. Which is why I kind of
wanted to get all of that kind of code out of our lower level libraries even
if in the end it makes absolutly no difference.

Besides, knowing microsoft you're putting your self at risk that in some
future revision of the framework prematurly calling dispose on a dataset
will all of the sudden become unsafe, and we'd really be in a bind then.

Carlo
 
Besides, knowing microsoft you're putting your self at risk that in some
future revision of the framework prematurly calling dispose on a dataset
will all of the sudden become unsafe, and we'd really be in a bind then.

Microsoft has cleary defined the purpose of the dispose.
It that happens and it might happen it would be entirely your fault.
You have to call Dispose only when you are finished with the object that
implements IDisposable (and you have to call it always when you are dealing
with such objects to be on the safe side).
 
It's me who is in error here and I'm sorry for that. Like I've said in my
second post, it's funny how fast you can sometime forget about some basic
principles of a language after a few months (or a year) of inactivity.
 
Back
Top