try { DataReader } catch { 22 }

[Guest]

Hi all,

I have a minor problem,

The MSDN documentation say that a DataReader must always be explicitly
closed in your code.

Now .. If I assign a DataReader in a try block (as one really should) and
then assume that an exception could be thrown by some other code in that try
block, it seems reasonable to me that I should close the DataReader int the
catch block, as well as the try block.

If I do this the compiler complains about using an unassigned local variable
int the catch block .. tut!

So .. I put the close command in the finally block .. same compiler error ..
hmmm.

The question is .. Do I really have to assign the DataReader in a try-catch
all it's own to ensure that I can subsequently close it, even if another
exception is thrown elsewhere?

Any enlightenment very much appreciated.

MFK.

 

[Andreas Mueller]

Hi all,

I have a minor problem,

The MSDN documentation say that a DataReader must always be explicitly
closed in your code.

Now .. If I assign a DataReader in a try block (as one really should) and
then assume that an exception could be thrown by some other code in that try
block, it seems reasonable to me that I should close the DataReader int the
catch block, as well as the try block.

If I do this the compiler complains about using an unassigned local variable
int the catch block .. tut!

So .. I put the close command in the finally block .. same compiler error ..
hmmm.

The question is .. Do I really have to assign the DataReader in a try-catch
all it's own to ensure that I can subsequently close it, even if another
exception is thrown elsewhere?

Any enlightenment very much appreciated.

MFK.

You can get rid of the error in this way:

DataReader r = null;
try{
r = new DataReader();
}
finally{
r.Close()
}

As DataReader implements IDisposable, you can use the using statement:

using(DataReader r = new DataReader()){
// do something
}//calls r.Dispose()

HTH,
Andy

 

[Guest]

Hi all,

I have a minor problem,

The MSDN documentation say that a DataReader must always be explicitly
closed in your code.

Now .. If I assign a DataReader in a try block (as one really should) and
then assume that an exception could be thrown by some other code in that try
block, it seems reasonable to me that I should close the DataReader int the
catch block, as well as the try block.

If I do this the compiler complains about using an unassigned local variable
int the catch block .. tut!

So .. I put the close command in the finally block .. same compiler error ..
hmmm.

The question is .. Do I really have to assign the DataReader in a try-catch
all it's own to ensure that I can subsequently close it, even if another
exception is thrown elsewhere?

Any enlightenment very much appreciated.

MFK.

The solution is to not use the same try block to catch errors when
opening the data reader as the one you use to make sure that the reader
is closed properly:

try {
Create reader here
try {
Read data
} finally {
Close reader here
}
} catch (SqlException e) {
Handle error
}

You can use the using statement to handle closing of the reader:

try {
using(Create reader here) {
Read data
}
} catch (SqlException e) {
Handle error
}

A the end of the using block, the reader will be closed automatically.

 

[Morten Wennevik [C# MVP]]

Hi all,

I have a minor problem,

The MSDN documentation say that a DataReader must always be explicitly
closed in your code.

Now .. If I assign a DataReader in a try block (as one really should) and
then assume that an exception could be thrown by some other code in that try
block, it seems reasonable to me that I should close the DataReader int the
catch block, as well as the try block.

If I do this the compiler complains about using an unassigned local variable
int the catch block .. tut!

So .. I put the close command in the finally block .. same compiler error ..
hmmm.

The question is .. Do I really have to assign the DataReader in a try-catch
all it's own to ensure that I can subsequently close it, even if another
exception is thrown elsewhere?

Any enlightenment very much appreciated.

MFK.

Hi MFK

using(SqlDataReader reader = new SqlDataReader(...))
{
// mapping code here
}

The above is equal to

SqlDataReader reader = null;

try
{
reader = new DataReader(...);
// mapping code here
}
finally
{
if(reader != null)
reader.Dispose();
}

 

[=?ISO-8859-15?Q?G=F6ran_Andersson?=]

Hi MFK

using(SqlDataReader reader = new SqlDataReader(...))
{
// mapping code here
}

The above is equal to

SqlDataReader reader = null;

try
{
reader = new DataReader(...);
// mapping code here
}
finally
{
if(reader != null)
reader.Dispose();
}

Actually, it's equivalent to:

reader = new DataReader(...);
try {
// mapping code here
} finally {
if(reader != null) {
reader.Dispose();
}
}

 

[Guest]

Andreas, Morten, Göran,

Thanks for the prompt responses guys.

I was not aware thet the using statement could be used in that way, I'm
still rather new to C#.

Problem solved, much appreciated.

MFK.

 

[Morten Wennevik [C# MVP]]

Actually, it's equivalent to:

reader = new DataReader(...);
try {
// mapping code here
} finally {
if(reader != null) {
reader.Dispose();
}
}

Are you sure? That would cause any exceptions during the construction of the object to be unhandled by the finally block.

 

[=?ISO-8859-15?Q?G=F6ran_Andersson?=]

Are you sure?

Yes, I am absolutely sure. I have compiled different code and compared
the generated code, to see exactly how the using statement works. If you
compile that code, it will show up as a using statement if you view it
in Reflector, as the generated code is indistinguishable from the code
generated by a using statement.

That would cause any exceptions during the construction of the object to be unhandled by the finally block.

Yes. If the construction of the object fails, then there is nothing to
dispose.

 

[Morten Wennevik [C# MVP]]

Morten Wennevik [C# MVP] wrote:

Hi all,

I have a minor problem,

The MSDN documentation say that a DataReader must always be explicitly
closed in your code.

Now .. If I assign a DataReader in a try block (as one really should) and
then assume that an exception could be thrown by some other code in that try
block, it seems reasonable to me that I should close the DataReader int the
catch block, as well as the try block.

If I do this the compiler complains about using an unassigned local variable
int the catch block .. tut!

So .. I put the close command in the finally block .. same compiler error ..
hmmm.

The question is .. Do I really have to assign the DataReader in a try-catch
all it's own to ensure that I can subsequently close it, even if another
exception is thrown elsewhere?

Any enlightenment very much appreciated.

MFK.



Hi MFK

using(SqlDataReader reader = new SqlDataReader(...))
{
// mapping code here
}

The above is equal to

SqlDataReader reader = null;

try
{
reader = new DataReader(...);
// mapping code here
}
finally
{
if(reader != null)
reader.Dispose();
}


Actually, it's equivalent to:

reader = new DataReader(...);
try {
// mapping code here
} finally {
if(reader != null) {
reader.Dispose();
}
}

Are you sure?

Yes, I am absolutely sure. I have compiled different code and compared
the generated code, to see exactly how the using statement works. If you
compile that code, it will show up as a using statement if you view it
in Reflector, as the generated code is indistinguishable from the code
generated by a using statement.

That would cause any exceptions during the construction of the object to be unhandled by the finally block.

Yes. If the construction of the object fails, then there is nothing to
dispose.

Good point

 

[Michael C]

You can get rid of the error in this way:

DataReader r = null;
try{
r = new DataReader();
}
finally{
r.Close()
}

What happends if the datareader creation fails?

Michael