1

I am very new to Java. I am writing a program to read a file, compute its SHA1 checksum, and write the result to another file. On any error I am calling a function err_exit() that prints a message to stderr and terminates execution by calling System.exit() with a specified exit status. This is approximately what my main() function looks like:

public static void main(String[] args) { String in_fname = "C:/tmp/test.txt"; // not reading args yet String out_fname = "C:/tmp/test.sign"; byte[] file_data; String hexdigest; try { file_data = readFileAsByteArray(in_fname); } catch (java.io.IOException ex) { file_data = new byte[] {0}; // note this line well, please err_exit(2, "error opening input file '" + in_fname + "'"); } try { hexdigest = hexdigestSha1(file_data); } catch (NoSuchAlgorithmException ex) { hexdigest = ""; // note this line well, please err_exit(3, "could not compute SHA1 message digest!"); } try { writeFileFromString(out_fname, hexdigest); } catch (java.io.IOException ex) { err_exit(2, "error writing output file '" + out_fname + "'"); } System.exit(0); // success }

There are two lines that I asked you to note well. Both of those lines exist simply to keep the compiler from complaining that the variable might not be initialized.

As far as the compiler can tell, the catch block might continue. Actually err_exit() will never return so there is no chance of an invalid value being passed along.

So, my question: what is the usual Java idiom for handling this sort of thing? The row of try/catch blocks is sort of ugly; would you recommend I make the various functions call err_exit() and not have the code explicit like this? I think I prefer the explicit checks, and the main() function is the right place to do the checking, but I'm interested in feedback.

If I am going to have the try/catch blocks, is this a good way to silence the compiler warnings?

If I were doing this in Python, I'd likely just not catch the exceptions, and let the program stop with a stack trace. A stack trace on error won't shock the user of this program, since that user is me. It occurs to me that if I declared my main() function as throws Exception that I could then not catch the exceptions and it would behave something like Python. Is that a horrible idea that would make right-thinking Java people shun me?

P.S. If you have a favorite book/web page/whatever of Java idioms that I should read, please mention it.

EDIT: I apologize for the variable names with underscores. I have already renamed the ones in my real program, but I am going to leave them as-is here. It's actually because I have spent a lot of time programming in Python and C; I was either using Python "PEP 8" style or generic C style, take your pick.

Improve this question
2
  • post the lines where you declare those two variables. Commented Mar 23, 2012 at 5:35
  • I added the missing stuff to make it a complete function. It looks better because StackOverflow is doing syntax coloring now... it wasn't before! Commented Mar 23, 2012 at 5:41

4 Answers 4

Reset to default
2

You seem to have a strong C background. I assume the compiler complains about variables such as file_data. Simply add file_data = null above the try-catch block.

Some points on the above:

  1. I think it is safe to combine all the statements in a single block. When an exception is thrown, the program will branch to the correct exception block immediately. It will also look far less ugly.
  2. Usually another method is not called within the catch-block as the task should (usually and if possible) be short and to the point. Handle the error, continue or exit (possibly be re-throwing the exception).
  3. System.exit() is evil. Rather throw a wrapped RuntimeException if you want the system to exit (i.e. an unrecoverable error condition). System.exit() may result in non-clean exists. Rather use throw new RuntimeException(e);
  4. Lastly, and if I may be as blunt, the Java convention is to write method/variable names as errExit, rather than err_exit.
Improve this answer
Sign up to request clarification or add additional context in comments.

7 Comments

Hmmm. Before I post a question, I always search StackOverflow to see if it has been answered. There are numerous discussions of the error "this variable might not have been initialized" and in several of them the advice was "don't initialize the variable until you need it; you want to let the compiler help you, and if you declare/init the variable the compiler is less able to help you." Do you disagree with that advice in general, or just in cases like I show here?
I see you edited your question :-) In terms of warnings, try byte[] file_data = null; The RuntimeException will display the stack trace for you... so I think that is what you want.
I think initialising to avoid the compiler complaining is fine. Usually lazy initialisation makes perfect sense, but only in cases where the actual value (i.e. non-null) is known. I've been using the "variable = null;" for local variables for ages... I will be most surprised if someone tells me it is bad style (and I would definitely want an alternative).
I'm not sure I understand your concern about being blunt, but I agree that the name err_exit() is not using the Java idiom. I will change it in my real program, but I think I'll leave it alone here. (Yes, I have a strong C background; well spotted.)
Well, some people get very angry if something as trivial as variable name convention is pointed out. Yes, it is definitely not critical. :-)
|
2

The compiler understands that a throw will never return, it does not understand that err_exit() will not return. If you were to re-write using the exceptions you are ignoring then your code could be cleaner and compiler happier. You could also consider using Java naming conventions.

public static void main(String[] args) { String inFname = "C:/tmp/test.txt"; // not reading args yet String outFname = "C:/tmp/test.sign"; try { processFile(inFname, outFname); } catch (Exception e) { e.printStackTrace(); throw e; // rethrow and let main() die } } public static void processFile(String inFname, String outFname) throws IOException, NoSuchAlgorithmException { Byte[] fileData = readFileAsByteArray(inFname); String hexDigest = hexdigestSha1(fileData); writeFileFromString(outFname, hexDigest); }

In the calling routine you can catch the errors. If you really need to distinguish between the the different places IOException could occur then you could catch in your routine and throw a descriptive error.

The minimal fix to your code is just to initialize your variables to null outside of the try catch blocks that set them. Then the compiler would be happy.

Improve this answer

2 Comments

Remember, total Java newbie here. Putting together your answer with Jaco Van Niekerk's answer, I guess I specify a message like "Unable to read file some_file_name" by passing it to new RuntimeException(mesg).
If I could accept two answers, I would also have accepted this one. I did upvote it. Thanks.
2

Personally, I like to "throw null;" after calling a method that simply cannot return.

Improve this answer

Comments

0

If I were positive that I'd be exiting immediately after a failed access, with no attempt to act on the results of the readFileAsByteArray, etc. calls, I'd probably assign null values at the declaration site. Something like this...

byte[] file_data = new byte[] {0};

... the rest of your code follows, without the "bogus" assignments in the catch blocks.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.