Exception handling and snarky compiler

I am trying to set up a random access file RanFile.
(sorry, I don't have my code with me)

I have confirmed or created the directory, I have confirmed or created
the file in a File object, and then I create the random file
try { RanFile = new RandomAccessFile(File, "rw" ); }
catch ( < exceptions> ),
{ < put out informative error, and exit program > }

Then I use RanFile
RanFile.seek(0L);
and the compiler complains that RanFile may not be initialized. Now I
know that if it wasn't, then the program would have ended by this
point. How do I convince the compiler of that?

Thanks.

Tom A.

On 27/08/2008 16:00, Tom A. allegedly wrote:
> I am trying to set up a random access file RanFile.
> (sorry, I don't have my code with me)
>
> I have confirmed or created the directory, I have confirmed or created
> the file in a File object, and then I create the random file
> try { RanFile = new RandomAccessFile(File, "rw" ); }
> catch ( < exceptions> ),
> { < put out informative error, and exit program > }
>
> Then I use RanFile
> RanFile.seek(0L);
> and the compiler complains that RanFile may not be initialized. Now I
> know that if it wasn't, then the program would have ended by this
> point. How do I convince the compiler of that?

When you declare the variable, set it to null. It's a bit annoying, but
that's how it is.

--
DF.

On 27-8-2008 16:00, Tom A. wrote:
> I am trying to set up a random access file RanFile.
> (sorry, I don't have my code with me)
>
> I have confirmed or created the directory, I have confirmed or created
> the file in a File object, and then I create the random file
> try { RanFile = new RandomAccessFile(File, "rw" ); }
> catch ( < exceptions> ),
> { < put out informative error, and exit program > }


>
> Then I use RanFile
> RanFile.seek(0L);
> and the compiler complains that RanFile may not be initialized. Now I
> know that if it wasn't, then the program would have ended by this
> point. How do I convince the compiler of that?
>
> Thanks.
>
> Tom A.
>

I assume you are using System.exit(status) to exit the program.

To the compiler calling the System.exit method is just like calling any
other method: it expects a normal return from the call. The compiler
doesn't (have to) know that a call to the System.exit method will not
return normally but terminates the JVM -- in most cases that is:
System.exit might throw a SecurityException if your code runs with a
security manager in place which doesn't allow your code to exit the JVM.

So the compiler finds that there is an execution path (out of the catch
block) in which the RanFile variable wasn't initialized.

To get rid of the error, initialize the variable with null at its
declaration ( /*A*/ in the example code below). This is the best
solution IMO. Alternative 1 is assign null to the variable after the
System.exit call (). The second alternative is to put a return statement
there ( /*B*/ ).


public void process(String fileName) {
RandomAccessFile file /*A*/;
try {
file = new RandomAccessFile(fileName, "r");
} catch (FileNotFoundException ex) {
System.out.println("Couldn't open " + fileName);
System.exit(1);
/*B*/
}

// Error on the line below: "The local variable
// 'file' may not have been initialized"
file.seek(0);


// and other stuff
}
--
Regards,

Roland

On Wed, 27 Aug 2008 07:00:44 -0700 (PDT), "Tom A."
<meteoricshipyards@yahoo.com> wrote, quoted or indirectly quoted
someone who said :

>try { RanFile = new RandomAccessFile(File, "rw" ); }

See http://mindprod.com/applet/fileio.html

and get it to generate you the sample code. The devil is in the
details and the code you have shown would not compile.
--

Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com

Roland de Ruiter wrote:
> To get rid of the error, initialize the variable with null at its
> declaration ( /*A*/ in the example code below). This is the best
> solution IMO.
I disagree. More to follow.

> Alternative 1 is assign null to the variable after the
> System.exit call (). The second alternative is to put a return statement
> there ( /*B*/ ).
This is a better approach, but there are better still.
>
>
> public void process(String fileName) {
> RandomAccessFile file /*A*/;
> try {
> file = new RandomAccessFile(fileName, "r");
> } catch (FileNotFoundException ex) {
> System.out.println("Couldn't open " + fileName);
> System.exit(1);
> /*B*/
> }
>
> // Error on the line below: "The local variable
> // 'file' may not have been initialized"
> file.seek(0);
>
>
> // and other stuff
> }

There are at *least* two other approaches. One is to put the "file.seek"
code within your try/catch block. The better approach is to throw an
exception from process, and let the code calling process worry about
exiting or not.

If nothing else, I would throw new AssertError("Never reaches this
point"); at position *B* above.
--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>

Tom A. wrote:
> I have confirmed or created the directory, I have confirmed or created
> the file in a File object, and then I create the random file
> try { RanFile = new RandomAccessFile(File, "rw" ); }
> catch ( < exceptions> ),
> { < put out informative error, and exit program > }
>
> Then I use RanFile
> RanFile.seek(0L);
> and the compiler complains that RanFile may not be initialized. Now I
> know that if it wasn't, then the program would have ended by this
> point. How do I convince the compiler of that?

There is another two ways to write the code that weren't mentioned yet and
which are even better. One way is to simply not catch the exception. In
fact if your code contains lots of small try/catch/exit blocks, it
effectively converts exceptions to errorcodes with a weird syntax, i.e. the
whole gain of exceptions is lost. Instead, use just a single catch block in
the main function, output an error message and return. Alternatively, you
can even leave that out and just let the program be terminated by an
uncaught exception.

This doesn't always work though, in particular when a function isn't allowed
to throw that kind of exception or when you want to output additional
information. In that case, you can catch and rethrow another exception,
typically of the type that is allowed or one that contains the additional
info. In a catch block further up, you then catch the exception, output the
additional info and terminate.

As a general rule, I find it clearer to not catch exceptions if I don't
handle them. However, there are other people who object to that rule, so
you will have to make your own judgement.

Uli

--
Sator Laser GmbH
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932

On Aug 28, 7:55*am, Ulrich Eckhardt <eckha...@satorlaser.com> wrote:
> Tom A. wrote:
> > I have confirmed or created the directory, I have confirmed or created
> > the file in a File object, and then I create the random file
> > * *try { * RanFile = new RandomAccessFile(File, "rw" ); }
> > * *catch ( *< exceptions> ),
> > * *{ < put out informative error, and exit program > * *}
>
> > Then I use RanFile
> > RanFile.seek(0L);
> > and the compiler complains that RanFile may not be initialized. *Now I
> > know that if it wasn't, then the program would have ended by this
> > point. *How do I convince the compiler of that?

Thank you, everyone who answered. The first suggestion (to initialize
the variable to null) fixed the problem. I was under the assumption
that it defaulted to null, and thus initializing it that way wouldn't
help the situation (because null.seek(long) wouldn't work either, and
I assumed the compiler was complaining about that).

Adding return; statements is another good idea.

> There is another two ways to write the code that weren't mentioned yet and
> which are even better. One way is to simply not catch the exception. In
> fact if your code contains lots of small try/catch/exit blocks, it
> effectively converts exceptions to errorcodes with a weird syntax, i.e. the
> whole gain of exceptions is lost.

I'm not sure what you mean by this; but as the coding progressed, I
did start putting larger chunks of code into the try/catch blocks.
But being new to this, I was concerned that I know what exactly went
wrong (if something did).




>
> As a general rule, I find it clearer to not catch exceptions if I don't
> handle them. However, there are other people who object to that rule, so
> you will have to make your own judgement.
>
> Uli

"Never test for an exception that you don't know how to handle."

Thanks everyone for the help.

Tom A.

On 28/08/2008 16:22, Tom A. allegedly wrote:
> On Aug 28, 7:55 am, Ulrich Eckhardt <eckha...@satorlaser.com> wrote:
>> There is another two ways to write the code that weren't mentioned yet and
>> which are even better. One way is to simply not catch the exception. In
>> fact if your code contains lots of small try/catch/exit blocks, it
>> effectively converts exceptions to errorcodes with a weird syntax, i.e. the
>> whole gain of exceptions is lost.
>
> I'm not sure what you mean by this; but as the coding progressed, I
> did start putting larger chunks of code into the try/catch blocks.
> But being new to this, I was concerned that I know what exactly went
> wrong (if something did).

Given that RandomAccessFile#seek(long) also throws an Exception
potentially, you must have another try..catch out there. It might be a
good idea to put it all in one block. I don't quite like the habit of
putting (to take it to the extreme) each statement that might fail
abruptly in a separate try..catch block -- but I can't entirely disagree
with you in this case, given that those are IOExceptions at hand, and
that the IOException hierarchy is rather badly designed (many
functionally different IOExceptions differ only by their respective
message).

If you worry about "putting larger chunks of code into the try/catch
blocks", separate your operations into logical steps, put each of these
in its own, throwing method and call these methods from within a
try..catch block. If you really have to distinguish between exception
causes, and the API hinders you (as it does in some respects with the
IOExceptions), you might catch Exceptions from each of the
aforementioned methods, wrap in into a more appropriate Exception, and
re-throw it.

--
DF.