Re: try...catch and local variables
- From: "Peter Duniho" <NpOeStPeAdM@xxxxxxxxxxxxxxxx>
- Date: Tue, 21 Nov 2006 15:42:42 -0800
"Mythran" <kip_potter@xxxxxxxxxxx> wrote in message
news:uZ5b58YDHHA.1196@xxxxxxxxxxxxxxxxxxxxxxx
By just looking at the code and error, I see you are in fact not assigning
oProcessFileReader before using it. Even though you are checking for
null, the compiler isn't smart enough to notice and it results in the
error you are getting.
The compiler does notice that he's checking for null. The problem is that
he's not allowed to check for null until he's set the variable to null. He
really does have an uninitialized variable bug in his code.
[...]
Note: This is simply a compiler error and I'm not sure if you can turn
off this functionality. It exists to prevent you from doing something
more like:
StreamReader reader;
reader.ReadLine();
Which is obviously bad, so the compiler warns/throws a tantrum when you
try to do something that even remotely resembles this...
In this particular case, there *is* a code path that can result in the local
variable being accessed before being initialized, without initialization in
the declaration. Initializing the local variable is indeed the correct
solution to the error, and is also correct relative to the rest of the code
that was posted.
However, unfortunately the compiler sometimes also incorrectly complains
that the variable is uninitialized, even when all code paths *do* initialize
the variable before it's accessed.
IMHO, this is a serious compiler bug, because the only way to get rid of the
error is to put in a "dummy" initialization (such as setting the variable to
null), which consequentially will hide any true "uninitialized variable"
errors in the code.
In other words, with the compiler in the state in which it is now, there are
actually situations in which the compiler forces the programmer to write
code that is *more* likely to contain the bug that the error is trying to
help avoid. I'd find the irony very entertaining, if it weren't for the
fact that there's a serious code quality issue related to it. :)
Pete
.
- Follow-Ups:
- Re: try...catch and local variables
- From: Mythran
- Re: try...catch and local variables
- References:
- Re: try...catch and local variables
- From: Mythran
- Re: try...catch and local variables
- Prev by Date: Re: C# Equivalent of C++ MD5 Algorith
- Next by Date: Re: try...catch and local variables
- Previous by thread: Re: try...catch and local variables
- Next by thread: Re: try...catch and local variables
- Index(es):
Relevant Pages
|