StreamReader/StreamWriter

You can use the profiler to see what is happening in your app's lifetime

http://msdn.microsoft.com/en-us/library/ms979205.aspx

Quote:

---

Originally Posted by George2

...Even though I am not using "using" and since the traffic is low, I do not meet with any issues...

---

Sounds to me like: ' hey boys I'm driving a car since years without using security belts also driving with high speed... Here me friends ... never have had an accident.'

Hmm. Is this really a good explanation why people shouldn't use security belts. ?;)

I think most people will disagree:D Me too.
All this mechanics like Dispose, Using, finally ... are done for having well designed code, which doesn't lead to troubles by the leak of simple basics.

Quote:

---

Originally Posted by eclipsed4utoo

Per Microsoft..

http://msdn.microsoft.com/en-us/library/ms228629(VS.80).aspx

---

Download the Runtime (or use reflector), and LOOK. The ONLY place where it is checked is inside the allocation routine.

Quote:

---

Originally Posted by George2

Thanks eclipsed4utoo,


1.

I think in your situation of "too many users are connected" is not because your code has bug which does not free handle, but because of GC does not free handles immediately?

2.

I think using Dispose call explicitly will solve this issue. :-)




regards,
George

---

George, what do you see as the downside of using a using block?

Thanks TheCPUWizard and eclipsed4utoo!


TheCPUWizard's comment for post #13 and eclipsed4utoo's post #14 seems both have formal resources or documents to support, but seems quite conflicting. Does anyone have any ideas what is the actual behavior? :-)

I am confused but interested.

Quote:

---

Originally Posted by eclipsed4utoo

Per Microsoft..

http://msdn.microsoft.com/en-us/library/ms228629(VS.80).aspx

---

regards,
George

Thanks Arjay,


1.

The downside is, I have to use Reflector to see what code is generated in order to understand the behavior. :-)

Just imagine the next version of C# compiler, the expanded code will change.

My current concern is, will expanded code catch all exceptions, or catch just Stream related exceptions or catch no exceptions and rethrow?

2.

If the exception is not re-throw, I have no chance to record a log for further problem determination. Any comments?

Quote:

---

Originally Posted by Arjay

George, what do you see as the downside of using a using block?

---

regards,
George

Thanks JonnyPoet,


I do not use some technologies because I have no knowledge about them, not because them are bad -- to be honest. :wave: ;)

BTW: I have written down my concerns about using block in my post #21. Any ideas?

Quote:

---

Originally Posted by JonnyPoet

Sounds to me like: ' hey boys I'm driving a car since years without using security belts also driving with high speed... Here me friends ... never have had an accident.'

Hmm. Is this really a good explanation why people shouldn't use security belts. ?;)

I think most people will disagree:D Me too.
All this mechanics like Dispose, Using, finally ... are done for having well designed code, which doesn't lead to troubles by the leak of simple basics.

---

regards,
George

Hi TheCPUWizard,


Can you let us know which function/class are you talking about please? I am interested to learn further from you. I think you want to prove GC is only worked when memory is not enough, not working regulaly.

Quote:

---

Originally Posted by TheCPUWizard

Download the Runtime (or use reflector), and LOOK. The ONLY place where it is checked is inside the allocation routine.

---

regards,
George

Quote:

---

Originally Posted by George2

My current concern is, will expanded code catch all exceptions, or catch just Stream related exceptions or catch no exceptions and rethrow?

---

but this has basically nthing to do with the usage of 'Using' or 'finally'
Both are to handle that your objects, streams, whatever are closed / disposed in a corrrect way when you dont need them anymore or when an exception is thrown. The exceptions aren't touched by them. The handling of exceptions is done in exactly that way your code will provide. Neither finally or Using throws any exceptions itself. This are two totally different shoes.

Thanks JonnyPoet,


Please feel free to correct me if I am wrong.

I think code,

Code:

---

    using(sr = new StreamReader())
    {
        do stuff…
    }

---

will be expanded by C# compiler like this,

Code:

---

    try
    {
        srObject.Open() ...
        read stuff etc...
    }
    catch
    {
        any exceptions ...
    }
    finally
    {
        srObject.close()
        srObject.dispose()
    }

---

There are two issues from the code,

- You can see all exceptions are eaten. From outside you can not catch any more exceptions -- e.g. write a log or something. The exception is not rethrown. :-)
- In finally block, no exception handled for Dispose/Close method.

Any comments?

Quote:

---

Originally Posted by JonnyPoet

but this has basically nthing to do with the usage of 'Using' or 'finally'
Both are to handle that your objects, streams, whatever are closed / disposed in a corrrect way when you dont need them anymore or when an exception is thrown. The exceptions aren't touched by them. The handling of exceptions is done in exactly that way your code will provide. Neither finally or Using throws any exceptions itself. This are two totally different shoes.

---

regards,
George

George, the generated code is more like:

Code:

---

try
{
  srObject.Open() ...
  read stuff etc...
}
finally
{
  srObject.close()
  srObject.dispose()
}

---

You can verify this yourself with the following

Code:

---

try
{
  using( Some IDisposable derived class )
  {
    // force or throw an exception here
  }
}
catch( Exception e )
{
  // see if this gets called
}

---

Quote:

---

Originally Posted by George2

My current concern is, will expanded code catch all exceptions, or catch just Stream related exceptions or catch no exceptions and rethrow?

---

You ONLY catch those exceptions that meet the following requirements

1) You know the basic cause of the exception, and are confident that the application environment is in a predictable state

2) You can take some type of "correct action".

If EITHER of these do not apply, then the proper thing to do is to simply let the exception propogate.


ps: Browse through mscorlib.dll as well as System.dll for the basic internals...

Thanks Arjay,


1.

I have made some test program and you are correct. I have posted my code below, and can you have a quick review about whether my test approach is correct please?

Code:

---

using System;
using System.Collections;
using System.Collections.Generic;
using System.Text;
using System.IO;
using System.Xml;

class Test
{

    class MyException : ApplicationException
    {
        public MyException (string message)
            : base(message)
        {

        }
    }

    class MyObject : IDisposable
    {
        public virtual void Dispose()
        {
            Console.WriteLine("Disposed ");
        }

    }

    public static void Main()
    {
        try
        {
            using (MyObject myobj = new MyObject())
            {
                throw new MyException("Hello World");
            }
        }
        catch (Exception ex)
        {
            Console.WriteLine(ex.ToString());
        }
    }
}

---

2.

I do not agree with you that Close method will be invoked, e.g. in your code "srObject.close()" -- I think only Dispose method is called. Any comments?

Quote:

---

Originally Posted by Arjay

George, the generated code is more like:

Code:

---

try
{
  srObject.Open() ...
  read stuff etc...
}
finally
{
  srObject.close()
  srObject.dispose()
}

---

You can verify this yourself with the following

Code:

---

try
{
  using( Some IDisposable derived class )
  {
    // force or throw an exception here
  }
}
catch( Exception e )
{
  // see if this gets called
}

---

---

regards,
George

Thanks TheCPUWizard,


One inferior point of using block is it does not catch exception occured in Dispose method. :-)

Any comments?

Quote:

---

Originally Posted by TheCPUWizard

You ONLY catch those exceptions that meet the following requirements

1) You know the basic cause of the exception, and are confident that the application environment is in a predictable state

2) You can take some type of "correct action".

If EITHER of these do not apply, then the proper thing to do is to simply let the exception propogate.


ps: Browse through mscorlib.dll as well as System.dll for the basic internals...

---

regards,
George

Quote:

---

Originally Posted by George2

I do not agree with you that Close method will be invoked, e.g. in your code "srObject.close()" -- I think only Dispose method is called.

---

Of course this depends on how the developer has implemented it. A developer would have to be a bit brain dead not to release resources (i.e. internally call Close()) before disposing themselves since it's the point of Dispose.

Fortunately, the .net class libraries I use seem to do this. SqlConnection, SqlCommand, File I/O (readers, writers), Message Queue all seem to do it.

It's just good practice.