Why is it necessary to use "throws IOException",

Question

Why does the main method use "throws IOException" during the processing of an external file operation if the file is on the local file system.

Answer 1

It is not necessary to use throws IOException. If you call a method that may throw an exception, you must either

• Catch him, or
• Announce that you are going to restore it.

The second is what you do. Another, which is often the preferred method, is to catch and handle the exception yourself:

 public static void main(String[] argv) { try { FileReader f = new FileReader("foo.txt"); // ... more } catch (IOException ioe) { System.out.println("Trouble reading from the file: " + ioe.getMessage()); } } 

Answer 2

It may not be necessary to add IOException to your main function, but it is necessary to do something to throw an exception. When you make an io file or io network or another (?) Io, something may go wrong. The file may not exist, it may be in a bad sector of the disk, the network may crash halfway (which may matter for the network or io file if the disk is not a local disk).

The reason you need to do something with an IOException is because it is a checked exception. If you call a constructor or function that throws a checked exception, you need to either handle it by catching it and take the appropriate action. Or you need to tell the compiler that you know about the exception, but you do not plan to do anything about it, in which case you should declare throws IOException in the definition of your function.

There is another type of exception that is excluded from the exception (sometimes called runtime exceptions, since they all extend the RuntimeException). Unchecked exceptions should have been potential runtime issues. for example, NullPointerException (NPE), an NPE example associated with execution conditions is that you expect to return an object, returns NULL, and then you try to call a method to do this. What a theory at least.

So you might think that runtime exceptions are for unexpected runtime problems, why is heck not an IOException exception at runtime? This is not like I was planning to fail, or to pull out half of the coast for an excavator-excavator in Schenectady. To scream out loud, I would also like to know! Someone give me Hallelujah, Oh, I hear you!

I did a ton of work related to IO in Java, and throws IOException seems like a thorn in the eye with which I just learned to live, because in general, it is a bad idea to try to handle IOExceptions at a low level because low-level code in general has no idea what the context of what you are trying to do is, and it should allow these exceptions to be flushed to code where there is a context of what you are trying to do.

Oh, and BTW, I mentioned that I would like to know why an IOException is not a run-time exception, whereas something like NPE? Yes, this is a condition of fulfillment, but IO (disk, network, whatever) is much less reliable than you think. If you are sure that the drive is reliable, check out some of the reasons why Sun invented ZFS. And if you think the network is reliable, try to make sure you have marketing content securely loaded in 15,000 shitty Windows-based kiosks due to lousy 3d party networks and make sure the client never sees a damaged image due to network problem. (Can you say that children ha ha-1-x-x, I knew I could).

I'm going somewhere with this; I promise.

I think the reason that an IOException is a checked exception is because IO is not reliable (look at error # 1 of distributed computing errors .) In general, you should be able to get NPE errors from your code, but IO - this is another beast, it is not reliable, and I think that their goal was to make you think about it. I mentioned that one of the authors of Fallalies of Distributed Computing is James Gosling. James Gosling, the same person who is considered the father of Java? Yes, this is my theory. Either that, or it was just a huge stupid mistake. There are a lot of early Java libraries.

There was a lot of controversy about the benefits of checked exceptions, and over time I came to an agreement with people who say that they are simply not worth the effort, and if there are cases when there are many prohibiting exclusions, exclusions will be declared, I will wrap them and reconstruct the corresponding Exception (say hi to my lil friend !). Despite this, I do not contact IOException; the wise thing is to live with pain.

Oh, and for the sake of simplicity, does one code all in the public static void main (String []) call the IOException function? The correct answer is to probably just give the bubble an exception and let the poor guy who is trying to run your code report this.

Thanks good night.

Answer 3

AFAIK, this is optional.

You either handle the exception or do not execute.

If you are handling an exception, you need to put try {...} catch(IOException e) {...} , but if you don't throw it, just throw throws IOException in the current method.

Answer 4

It is not necessary to throw an IOException at all ..... But it is a good habit to throw an IOException or fileNotFoundException, and then catch it so that if your file is not found, the program will not explode and gives an error message.

You will need to use Try and catch. Here is a snippet of code that might be useful ...........

 Scanner fileScanner = null; try { fileScanner = new Scanner(new File("YOUR FILE PATH")); while(fileScanner .hasNextLine()) { String eachLine= scanner.nextLine(); String[] wordsFromFile = eachLine.split("\\W"); } } catch(FileNotFoundException e) { System.err.println("Cannot find the file"); } finally { if(scanner!= null) scanner.close(); } 

Answer 5

This is not necessary, but at least you need to either handle the exception, or you don’t. If you handle the exception, then you need to put try {...} catch(IOException e) {...} , but if you don't handle, just declare throws IOException in the current method.