There is no IsDisposed() method. I could just access it, and catch
ObjectDisposedException, but that seems ugly.
Zytan
31  11302 
Hello Zytan,
What are u gonna reproduce? Maybe usin' WeakReference helps u?
---
WBR, Michael Nemtsev [C# MVP].
My blog: http://spaces.live.com/laflour
Team blog: http://devkids.blogspot.com/
"The greatest danger for most of us is not that our aim is too high and we
miss it, but that it is too low and we reach it" (c) Michelangelo
ZThere is no IsDisposed() method. I could just access it, and catch
ZObjectDisposedException, but that seems ugly.
Z>
ZZytan
Z>
Hi,
What are you trying to do?
"Zytan" <zy**********@gmail.comwrote in message
news:11**********************@l77g2000hsb.googlegr oups.com...
There is no IsDisposed() method. I could just access it, and catch
ObjectDisposedException, but that seems ugly.
Zytan
Zytan <zy**********@gmail.comwrote:
There is no IsDisposed() method. I could just access it, and catch
ObjectDisposedException, but that seems ugly.
I've never been in the situation where I have a reference to something
but don't know whether or not it's been disposed - what's your
situation? Can you avoid it somehow?
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
If it has a Dispose method and it is implemented according to the recommended
pattern, you can call the Dispose method without concern whether it is
Disposed or not, catching the ObjectDisposed exception.
How could we expect to call an "IsDisposed" method on an object that is no
longer there? I'm not sure that makes any sense.
Cheers,
Peter
--
Site: http://www.eggheadcafe.com
UnBlog: http://petesbloggerama.blogspot.com
Short urls & more: http://ittyurl.net
"Zytan" wrote:
There is no IsDisposed() method. I could just access it, and catch
ObjectDisposedException, but that seems ugly.
Zytan
Peter Bromberg [C# MVP] <pb*******@yahoo.yabbadabbadoo.comwrote:
If it has a Dispose method and it is implemented according to the recommended
pattern, you can call the Dispose method without concern whether it is
Disposed or not, catching the ObjectDisposed exception.
How could we expect to call an "IsDisposed" method on an object that is no
longer there? I'm not sure that makes any sense.
It does - disposed != not there. Something can certainly be disposed of
while there are still references to it, and you could conceivably want
to make sure you don't call other methods (eg Write) on something which
is disposed. I'd argue that it's best not to get into such a situation
in the first place though.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Zytan wrote:
There is no IsDisposed() method. I could just access it, and catch
ObjectDisposedException, but that seems ugly.
I do not know if it is "supported" but the following both
seems to work and do make some sense:
sw.BaseStream != null && sw.BaseStream.CanWrite
(actually that is IsNotDisposed() but who cares)
Arne
I do run into such situations in asynchronous Socket Callbacks. Try/Catch
keeps application running, but I am uneasy about this.
Michael
"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP************************@msnews.microsoft.c om...
Zytan <zy**********@gmail.comwrote:
>There is no IsDisposed() method. I could just access it, and catch
ObjectDisposedException, but that seems ugly.
I've never been in the situation where I have a reference to something
but don't know whether or not it's been disposed - what's your
situation? Can you avoid it somehow?
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
"Arne Vajhøj" <ar**@vajhoej.dkwrote in message
news:46***********************@news.sunsite.dk...
Zytan wrote:
>There is no IsDisposed() method. I could just access it, and catch
ObjectDisposedException, but that seems ugly.
I do not know if it is "supported" but the following both
seems to work and do make some sense:
sw.BaseStream != null && sw.BaseStream.CanWrite
(actually that is IsNotDisposed() but who cares)
Arne
This will throw a NullReferenceException when called on a disposed sw or sr .
What you actually want is this:
if(sw != null && sw.BaseStream != null)
// go ahead, the underlying resource is still accessible.
else
...
Anyway, I do prefer to handle the ObjectDisposedException.
Willy.
Hello Zytan,
>
What are u gonna reproduce? Maybe usin' WeakReference helps u?
In my logger, sometimes Finalizers want to call MyLogger.WriteLine()
and by this time, the underlying stream is already closed by the
framework. So, I want to see if it is closed (disposed) or not, so I
can re-open it, to make these last second Write's.
The easy way is to try catch ObjectDisposedException. I thought maybe
there's a prettier way.
Zytan
I do run into such situations in asynchronous Socket Callbacks. Try/Catch
keeps application running, but I am uneasy about this.
That's my thought. Perhaps I am just not comfortable with exceptions,
since they are for exceptional behaviour. But, maybe this is such a
thing.
Zytan
On Apr 3, 1:28 pm, "Zytan" <zytanlith...@gmail.comwrote:
What are u gonna reproduce? Maybe usin' WeakReference helps u?
In my logger, sometimes Finalizers want to call MyLogger.WriteLine()
That's where the problem is. Finalizers are designed to clean up
unmanaged state they know about - and nothing else. As soon as they
start relying on other things being present, you *will* run into
issues.
Personally, I can't remember the last time I wrote a finalizer. Cast
off your C++ idioms :)
Jon
It does - disposed != not there. Something can certainly be disposed of
while there are still references to it, and you could conceivably want
to make sure you don't call other methods (eg Write) on something which
is disposed.
Yes.
I'd argue that it's best not to get into such a situation
in the first place though.
Sometimes, its unavoidable. The run time of finalizers are almost
chaotic. And the framework closes file streams before the finalizer
of my own class that holds the only reference to the file stream has
been invoked, so there's nothing else I can do. I know loggers are an
extreme case, since they have to run at all times, and this is
unusual.
Zytan
What you actually want is this:
>
if(sw != null && sw.BaseStream != null)
// go ahead, the underlying resource is still accessible.
else
...
Anyway, I do prefer to handle the ObjectDisposedException.
Given the above code or the exception, I take the exception any day.
At least I know for 100% certainty that it will work, and it doesn't
rely on me understanding or typing the code example correctly.
Zytan
In my logger, sometimes Finalizers want to call MyLogger.WriteLine()
>
That's where the problem is. Finalizers are designed to clean up
unmanaged state they know about - and nothing else. As soon as they
start relying on other things being present, you *will* run into
issues.
That makes sense.
Personally, I can't remember the last time I wrote a finalizer. Cast
off your C++ idioms :)
To be honest, the finalizer is just for the purposed of seeing when it
is run, but since other people are using my logger class, and told me
that it wasn't working when called inside such finalizers, I figured
I'd make it work. And it does by catching the ObjectDisposedException
exception, re-opening, appending, closing the file. But, I thought
there would be a better way.
It's hard to say how some people may use the logger class. Maybe just
to print stats temporarily for debugging? Who knows. After all, it's
just a logger, and it can be viewed after the program is done, and it
is one of those things that you think conceptually can be called from
anywhere, even before your main functions are run, during construction
of static class data members. But, yes, I also can't see a reason for
production code to have a finalizer, as well.
Zytan
Hello Zytan,
You should take into account that CLR does not guarantee that finalizers
will be called at all.
Read this http://groups.google.com/group/micro...f2a3b55dbb8935
I suppose it exactly what are u trying to reproduce
---
WBR, Michael Nemtsev [C# MVP].
My blog: http://spaces.live.com/laflour
Team blog: http://devkids.blogspot.com/
"The greatest danger for most of us is not that our aim is too high and we
miss it, but that it is too low and we reach it" (c) Michelangelo
>Hello Zytan,
What are u gonna reproduce? Maybe usin' WeakReference helps u?
ZIn my logger, sometimes Finalizers want to call MyLogger.WriteLine()
Zand by this time, the underlying stream is already closed by the
Zframework. So, I want to see if it is closed (disposed) or not, so I
Zcan re-open it, to make these last second Write's.
Z>
ZThe easy way is to try catch ObjectDisposedException. I thought
Zmaybe there's a prettier way.
Z>
ZZytan
Z>
You should take into account that CLR does not guarantee that finalizers
will be called at all.
Really? I fail to understand why.
Read this http://groups.google.com/group/micro...languages.csha...
I suppose it exactly what are u trying to reproduce
No, not really, I just know that maybe some people will call my logger
class from their finalizers, and will wonder why the WriteLine's
didn't work (since the logger's file stream has been closed by the
CLR). So, I just wanted to make such calls re-open, append, close the
file in the case that the file stream is already closed.
I couldn't see from that thread where it says that there is no
guarantee that finalizers are called.
Zytan
Hello Zytan,
Because CLR has timeout for finalizing and only single finalized thread is
used, which can be stalled somewhere. http://msdn.microsoft.com/msdnmag/is...lt.aspx?loc=en
---
WBR, Michael Nemtsev [C# MVP].
My blog: http://spaces.live.com/laflour
Team blog: http://devkids.blogspot.com/
"The greatest danger for most of us is not that our aim is too high and we
miss it, but that it is too low and we reach it" (c) Michelangelo
>You should take into account that CLR does not guarantee that
finalizers will be called at all.
ZReally? I fail to understand why.
Z>
"Zytan" <zy**********@gmail.comwrote in message
news:11**********************@d57g2000hsg.googlegr oups.com...
>What you actually want is this:
if(sw != null && sw.BaseStream != null)
// go ahead, the underlying resource is still accessible.
else
...
Anyway, I do prefer to handle the ObjectDisposedException.
Given the above code or the exception, I take the exception any day.
At least I know for 100% certainty that it will work, and it doesn't
rely on me understanding or typing the code example correctly.
Zytan
Hmmm.... Didn't you notice that this was a reply to Arne, and that I was correcting his
sample?
Willy.
What you actually want is this:
>
if(sw != null && sw.BaseStream != null)
// go ahead, the underlying resource is still accessible.
else
...
Anyway, I do prefer to handle the ObjectDisposedException.
Given the above code or the exception, I take the exception any day.
At least I know for 100% certainty that it will work, and it doesn't
rely on me understanding or typing the code example correctly.
Zytan
Hmmm.... Didn't you notice that this was a reply to Arne, and that I was correcting his
sample?
Yes.
My reply meant that if given 2 choices: A. Arne's code (the correct
version), or B. handle ObjectDisposedException, I would choose B over
A any day. Because: for A to work, I have to make sure my code is
written correctly, and this is easy to screw up, especially for
someone not well versed in which properties to call, and it allows for
easy syntax errors that may be missed even when skimming over it. B,
on the other hard, is pretty much fool proof. It's hard to mess up an
exception handler for a specific exception.
In other words, my preference is the same as yours.
Zytan
"Zytan" <zy**********@gmail.comschrieb im Newsbeitrag
news:11**********************@p77g2000hsh.googlegr oups.com...
>I do run into such situations in asynchronous Socket Callbacks. Try/Catch
keeps application running, but I am uneasy about this.
That's my thought. Perhaps I am just not comfortable with exceptions,
since they are for exceptional behaviour. But, maybe this is such a
thing.
This surely is an exeptional behaviour. First, your logger class shouldn't
be called from a finalizer (though some might think it's usefull to do).
Second, the run of a finalizer itself should be exceptional. An application
running hundreds of finalizers per second surely has some bug and is in a
very very exceptional case.
If you still want to avoid this exception, you could use an instance
variable, wich marks, if the stream is open. I don't know, where you get the
stream from, but I think your logger class is the only class, wich can
dispose it.
Christof
"Christof Nordiek" <cn@nospam.deschrieb im Newsbeitrag
news:ui**************@TK2MSFTNGP02.phx.gbl...
<snip>
If you still want to avoid this exception, you could use an instance
variable, wich marks, if the stream is open. I don't know, where you get
the stream from, but I think your logger class is the only class, wich can
dispose it.
Hi Zytan,
reading one of your other posts, I noticed that this surely can fail. Your
right, the stream can be disposed by it's own finalizer. But then your
logger class has also to be in the finalizer qeue (if it has a finalizer
itself). This gives me another idea. Maybe there is a way to detect, if the
instance itself is pending for finalization. or only living because it's
referenced directly or indirectly by the finalizing qeue.
But still I suppose, the exception is best suited here.
Christof
reading one of your other posts, I noticed that this surely can fail. Your
right, the stream can be disposed by it's own finalizer. But then your
logger class has also to be in the finalizer qeue (if it has a finalizer
itself). This gives me another idea. Maybe there is a way to detect, if the
instance itself is pending for finalization. or only living because it's
referenced directly or indirectly by the finalizing qeue.
But still I suppose, the exception is best suited here.
Christof, thanks for your posts. I am not trying to avoid using the
exception handling at all costs, I just thought maybe there's a
Stream.IsDisposed method that I am missing, or something, so I want to
be sure I'm doing the right thing.
I think handling the exception is proper. And it's easy and basically
fool proof. All is well! :)
Zytan
Willy Denoyette [MVP] wrote:
"Arne Vajhøj" <ar**@vajhoej.dkwrote in message
news:46***********************@news.sunsite.dk...
>Zytan wrote:
>>There is no IsDisposed() method. I could just access it, and catch
ObjectDisposedException, but that seems ugly.
I do not know if it is "supported" but the following both
seems to work and do make some sense:
sw.BaseStream != null && sw.BaseStream.CanWrite
This will throw a NullReferenceException when called on a disposed sw or
sr .
No it will not.
sw.Dispose();
does not by magic set sw to null.
What you actually want is this:
if(sw != null && sw.BaseStream != null)
// go ahead, the underlying resource is still accessible.
else
...
The sw != null test is rather meaningless in the context
of the subject.
I have some doubts whether sw.BaseStream != null is sufficient. It
is based on the assumption that Dispose actually sets BaseStream
to null. Current implementation does. But if a future implementation
just call Dispose and do not set it to null, then the code will break.
I think sw.BaseStream.CanWrite is a nice extra check to have.
Arne
Zytan wrote:
>What you actually want is this:
if(sw != null && sw.BaseStream != null)
// go ahead, the underlying resource is still accessible.
else
...
Anyway, I do prefer to handle the ObjectDisposedException.
Given the above code or the exception, I take the exception any day.
At least I know for 100% certainty that it will work, and it doesn't
rely on me understanding or typing the code example correctly.
You could wrap it in a method.
But I would also use the exception !
Arne
Willy Denoyette [MVP] wrote:
Hmmm.... Didn't you notice that this was a reply to Arne, and that I was
correcting his sample?
Messing it up.
Arne
Well, the concept of exceptions is hardly new and was around well before the
framework. I am uneasy that I am using .NET exception handling in situations
where functionally similar Win32 code would never raise an exception to
begin with. I have written TCP/IP client/servers using asynchronous model
(WSAAsyncSelect) and any socket to 'bite the dust', would send a message to
the a window it registered with. I had applications running around the clock
for several month serving data over DSL connections without ever raising an
exception. The .NET version also runs around the clock, however I see from
my logs that exceptions occur once in a while, sometimes days apart,
sometimes several times a day. Keeps me wondering if Win32 Winsock model is
better.
Michael
"Zytan" <zy**********@gmail.comwrote in message
news:11**********************@p77g2000hsh.googlegr oups.com...
>I do run into such situations in asynchronous Socket Callbacks. Try/Catch
keeps application running, but I am uneasy about this.
That's my thought. Perhaps I am just not comfortable with exceptions,
since they are for exceptional behaviour. But, maybe this is such a
thing.
Zytan
"Arne Vajhøj" <ar**@vajhoej.dkwrote in message
news:46***********************@news.sunsite.dk...
Willy Denoyette [MVP] wrote:
>"Arne Vajhøj" <ar**@vajhoej.dkwrote in message
news:46***********************@news.sunsite.dk. ..
>>Zytan wrote:
There is no IsDisposed() method. I could just access it, and catch
ObjectDisposedException, but that seems ugly.
I do not know if it is "supported" but the following both
seems to work and do make some sense:
sw.BaseStream != null && sw.BaseStream.CanWrite
>This will throw a NullReferenceException when called on a disposed sw or sr .
No it will not.
Sure it will , try this...
.....
StreamReader sr = null;
using ( sr = new StreamReader("canread.cs"))
{
.....
} // sr Disposed here.
if(sr != null && sr.BaseStream.CanRead)
Console.WriteLine("Stream can still be read from");
It will throw...
Unhandled Exception: System.NullReferenceException: Object reference not set to
an instance of an object.
sw.Dispose();
does not by magic set sw to null.
>What you actually want is this:
if(sw != null && sw.BaseStream != null)
// go ahead, the underlying resource is still accessible.
else
...
The sw != null test is rather meaningless in the context
of the subject.
I have some doubts whether sw.BaseStream != null is sufficient. It
is based on the assumption that Dispose actually sets BaseStream
to null. Current implementation does. But if a future implementation
just call Dispose and do not set it to null, then the code will break.
I think sw.BaseStream.CanWrite is a nice extra check to have.
Note, that future implementations can hardly change this behavior (which I don't rely upon
anyway!), without introducing a breaking change, if you look at the current implementation
of the FCL, setting BaseStream to null is done especially to guard themselves against
further access of the underlying stream.
Anyway, currently, BaseStream is effectively set to null in the SW or SR's Dispose method ,
so, sw.BaseStream.CanWrite will throw a NullReferenceException after the sw is disposed, so
what's the deal, handle a NullReferenceException or an bjectDisposedException?
I prefer the latter, the first one is too confusing, you don't expect this, right?.
That's why I assume "A disposed object being a dead object", I won't use it any longer.
Willy.
On Apr 4, 10:08 am, "Willy Denoyette [MVP]"
<willy.denoye...@telenet.bewrote:
<snip>
No it will not.
Sure it will , try this...
....
StreamReader sr = null;
using ( sr = new StreamReader("canread.cs"))
{
....
} // sr Disposed here.
if(sr != null && sr.BaseStream.CanRead)
Console.WriteLine("Stream can still be read from");
It will throw...
Unhandled Exception: System.NullReferenceException: Object reference not set to
an instance of an object.
Yes, because the BaseStream is null, but *not* because sr is null. The
variable sr won't become null just because you called Dispose on the
object.
Arne's code tested for sw.BaseStream being null. Change your test code
above to the code that Arne originally posted and it won't throw a
NullReferenceException.
Now, your point that you *only* need to test for sw.BaseStream being
null is a valid one (if somewhat implementation-specific) but you
don't need to test for sw being null unless you've got some code which
changes the value of the variable.
Jon
"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:11*********************@q75g2000hsh.googlegro ups.com...
On Apr 4, 10:08 am, "Willy Denoyette [MVP]"
<willy.denoye...@telenet.bewrote:
<snip>
No it will not.
Sure it will , try this...
....
StreamReader sr = null;
using ( sr = new StreamReader("canread.cs"))
{
....
} // sr Disposed here.
if(sr != null && sr.BaseStream.CanRead)
Console.WriteLine("Stream can still be read from");
It will throw...
Unhandled Exception: System.NullReferenceException: Object reference not set to
an instance of an object.
Yes, because the BaseStream is null, but *not* because sr is null. The
variable sr won't become null just because you called Dispose on the
object.
Arne's code tested for sw.BaseStream being null. Change your test code
above to the code that Arne originally posted and it won't throw a
NullReferenceException.
Waw ... my bad, Jeez, I missed sw.BaseStream != null in Arnes's sample.
Note that the check for CanRead is redundant, if "sw.BaseStream != null" holds true it means
that the underlying stream isn't disposed of, so no further check is required.
Now, your point that you *only* need to test for sw.BaseStream being
null is a valid one (if somewhat implementation-specific) but you
don't need to test for sw being null unless you've got some code which
changes the value of the variable.
True, this is only a sanity check ;-)
Not that I'm ever going to use this.
Willy.
"Willy Denoyette [MVP]" <wi*************@telenet.bewrote in message
news:uI*************@TK2MSFTNGP04.phx.gbl...
"Arne Vajhøj" <ar**@vajhoej.dkwrote in message
news:46***********************@news.sunsite.dk...
>Willy Denoyette [MVP] wrote:
>>"Arne Vajhøj" <ar**@vajhoej.dkwrote in message
news:46***********************@news.sunsite.dk.. .
Zytan wrote:
There is no IsDisposed() method. I could just access it, and catch
ObjectDisposedException, but that seems ugly.
I do not know if it is "supported" but the following both
seems to work and do make some sense:
sw.BaseStream != null && sw.BaseStream.CanWrite
>>This will throw a NullReferenceException when called on a disposed sw or sr .
No it will not.
Sure it will , try this...
....
StreamReader sr = null;
using ( sr = new StreamReader("canread.cs"))
{
....
} // sr Disposed here.
if(sr != null && sr.BaseStream.CanRead)
Console.WriteLine("Stream can still be read from");
It will throw...
Unhandled Exception: System.NullReferenceException: Object reference not set to
an instance of an object.
Sorry, but forget about this sample, I misread the code sample you posted.
Willy.
Willy Denoyette [MVP] wrote:
Sorry, but forget about this sample, I misread the code sample you posted.
No problem.
I have misread post myself many times.
Worst - when I was really criticizing what I though was
pseudo code for not being valid C - when some one pointed
out that it was in a PHP category ...
Arne This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Wayne Wengert |
last post by:
I am trying to run a sample from the on-line help and I am getting the error
below on this line of code
Dim writer As TextWriter = New StreamWriter(filename)
The error is:
Type 'TextWriter'...
|
by: D |
last post by:
I have a winforms app that I'm reading some records from a datareader and
writing them out to a file like so
SqlDataReader dataReader = sqlCommand.ExecuteReader();
TextWriter textWriter = new...
|
by: fniles |
last post by:
Is this the correct syntax to make a Textwriter thread safe ? Thank you.
Dim swError As TextWriter
Dim swErrorSync As TextWriter
swError = New StreamWriter(Application.StartupPath & "\Log.txt",...
|
by: Zytan |
last post by:
I have a log class that makes a synchronized TextWriter like so, in
the constructor:
StreamWriter sw = new StreamWriter(filename);
tw = TextWriter.Synchronized(sw);
In the destructor,...
|
by: jtertin |
last post by:
I am currently using the following code to make sure a file is
writable (i.e. is not in use) by using the CanWrite method of the
FileStream object. Using the code below, the TextWriter is still...
|
by: Carla Simeoni |
last post by:
Some sample source codes use TextWriter other StreamWriter for writing text into a file.
What are the differences ?
Carla
|
by: kengtung |
last post by:
Greetings all,
I just started programming with C# (.Net FW 1.1) last year and still
learning. Previously I am using VB 6.0.
Recently, in one application, I encountered a C# error "Cannot write...
|
by: John |
last post by:
Hi
What is the difference between System.IO.TextWriter vs System.IO.TextWriter?
Thanks
Regards
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
| |
