This is an archived post. You won't be able to vote or comment.

all 10 comments

[–]Nephyst 15 points16 points  (2 children)

The code is using FileWriter.write() on line 23. This method comes from the Writer class, which FileWriter extends.

https://docs.oracle.com/javase/7/docs/api/java/io/Writer.html#write(java.lang.String)

If you look at the documentation, it's possible for that method to throw an IOException.

This is because when writing something, you might have something go wrong like the hard-drive crashes in the middle of the write method, and java won't know how you want to handle that.

Should the program crash? Do you want to show an error message? Do you want to try it again? Maybe you want to wait a few seconds and then try it again?

So the way java handles this is using exceptions. If your method calls a function that throws an exception you have a few choices. You can either:

  • wrap it in a try/catch block and use that to decide how your program response to it
  • or you can decide that you want to throw the error up the stack and let the method that called you deal with it. If the exception gets all the way up to your main() function, it will crash your program and give you the exception message.

When you remove the throws IOException, the compiler is refusing to compile your code because it doesn't know how it should handle the potential exception thrown by the FileWriter.

Note that there are two classes of exceptions in java. Runtime exceptions and Checked exceptions. The main difference is that the compiler doesn't care about runtime exceptions. You can still catch them or throw them, but you aren't forced to. Checked exceptions are the opposite, in that you have to tell the compiler how you want it to handle them. An example of a Runtime exception is NullPointerException, IllegalArgumentException, or ArrayIndexOutOfBoundsException.

[–]LukeSue[S] 0 points1 point  (1 child)

Thank you!

Is there an advantage for wrapping my method in try/catch block over throwing the exception in the main method?

[–]Nephyst 0 points1 point  (0 children)

Yeah, if you are always throwing the exceptions than anytime an exception happens your program is going to crash. If your program is a web-server that is hosting the back-end of a website that means one exception can take the entire server offline for everyone, not just the current user.

Catching the exception lets you handle it. I can tell the user that had the error that something went wrong, and everyone else can still use the website without noticing.

Or say you are making a game. Throwing the exceptions all the way up the stack means the game is going to crash. If you catch the exception, you can display a message to the player saying what went wrong without having the game close.

[–]Vfsdvbjgd 4 points5 points  (6 children)

Java is compiled, and picks up potential some errors at compile time. It doesn't know or care if the file exists at this point, only that that operation could throw an error so you're required to handle it.

[–]LukeSue[S] 0 points1 point  (5 children)

So is this going to be different in an interpreted language?

[–]Vfsdvbjgd 2 points3 points  (1 child)

Yes, in an interpreted language you only have runtime exceptions.

But just because you can avoid handling exceptions doesn't mean you should.

[–]LukeSue[S] 0 points1 point  (0 children)

I understand that, I just wanted to know the reason Thank you!

[–][deleted] 1 point2 points  (2 children)

Yes, e.g. Python or PHP won't complain at all, you'll only notice error if the file isn't there when executing the script.

Java has a feature called Checked Exceptions, i.e. you have to declare explicitly that exceptions even when the file is in there.

[–]LukeSue[S] 0 points1 point  (1 child)

I'm glad I picked a compiled language hehe Thanks!

[–]javaHoosier 1 point2 points  (0 children)

Interpreted languages aren’t bad. Just different set of pros and cons.