This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
I am fairly new to Java, and currently taking an intro class for a major in the IT field. I was sick last class, and I missed an important lesson(every lesson is important ). Here is an example of the code the teacher has posted on his site
Now I dont EXACTLY understand what the "throwing exception" is doing here. I have checked the Java Tutorials and from what I understand, "throwing an exception" has to do with some thing like covering your program from occurring an error. Howver, i do not think I am completely grasping the concept here. If someone can try to help me understand more of the uses of throwing an exception is would be extremely helpful. Thank you for your time in advance!
If you were to try to compile code which can cause an exception without "throws Exception", It won't compile. For certain things you must either have "throws Exception" or have the offending code in a try-catch block. (The compiler will tell you if it needs it when you try to compile). If you're in an intro class and haven't dealt with exception handling yet, it may be enough to know that the throws must be present for compilation.
I/O is one such thing that requires exception handling. Looking at the code you posted, I don't believe there is anything that would require the throws. I suspect that coding them is a habit your instructor wants you to get into.
Joined: Aug 23, 2004
Yes, the code is not to be compiled, but to not only get a habit of, but an understanding of. I just do not understand it.
You're exactly right that it has to do with an "error" occurring. An easy example is an IndexOutOfBoundsException, which could be thrown when running code that's accessing elements of an array and you access an invalid index (e.g. an index greater than the length of the array). Or how about a NullPointerException...say you try to get a substring of a String that is actually null. Well, if one of these exceptions got thrown, you might want to handle it right then and there, or you might want to pass it up the chain to let something else handle it.
Here's an example of handling it immediately:
So above we print out the exception to see exactly what it says. For some more detail, you might call e.printStackTrace() instead. Try both of these out and see what happens (also try to do other bad things to generate other kinds of exceptions).
When you catch an exception, you are in a sense telling your program to ignore that error and not crash--continue as if everything is all right (especially if you don't do anything in the catch block--that section of code gives you the opportunity to do something to fix the problem, or whatever it is that would be best to do at that point).
However, it might not be appropriate to catch the exception right there. What if you don't want anymore of the code in that method to execute if an exception occurs? In that case, it would be best to say that the method throws that potential type of exception, and let the method that called it determine what to do with the exception (or that method could also throw the exception further up the chain, and so on and so on).
Say I'm running through a list of items that I want to store in a database and I'm trying to determine which ones are suitable and which ones should be discarded. If a particular item generates an error, that might mean that it's not valid or I don't want it or something like that, so in my little analyzeItem() method, I might not catch the exception. If a couple of possible exceptions are NullPointerException and IndexOutOfBoundsException, I would declare it:
Then the method that called analyzeItem could catch the exception and decide that it doesn't want to attempt to store that item.
You also have the option of catching or throwing all exceptions by just saying "catch (Exception e)" in the try-catch block or "throws Exception" on the end of a method declaration, but you should consider this carefully. That little "e" could be whatever you decide to call it: err, theException, or whatever variable name you'd like to give it.
Hope that helps! Long enough answer for ya? It must be Saturday... [ October 23, 2004: Message edited by: Stephen Huey ]
Joined: Aug 23, 2004
Great answer Stephen! I understand more in depth now, but I need to try things out to fully grasp the concept.
Thanks for spending the time to help a beginner out!