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.
Marilyn, you gave me a comment to try not to throw a new exception if I can do it without one. I can write methods that return something like a -1 or something for errors so as to avoid throwing exceptions, but I thought the assignment specfically stated for us to throw an exception. Just wondering which way I should go. Bill PS Sorry about the spacing agina
Hello Bill, I'm guessing that Marilyn might not want you to create a new type of exception and use that, if that's the way you went. I just submitted my first version of this assignment myself and your question got me thinking about the new type of exception that I used, and whether or not it was really needed. I went back to the program and was able to trim quite a few lines of code by just using the existing "Exception" class. I'm expecting the nit-picker to hammer me for my potentially unnecessary class, and I'll be ready with version two.
Throw an exception with text for the user to see in one method.� Have your main method catch the exception and show it to the user. You don't need to throw a new exception in each method.
JavaBeginnersFaq "Yesterday is history, tomorrow is a mystery, and today is a gift; that's why they call it the present." Eleanor Roosevelt
Joined: Jun 30, 2000
OK, I resubmitted. I kind of feel the code I had last time was cleaner, but I was having trouble finding a way to not throw a new exception if I broke things out into two methods, one that takes a String and returns the int (toInt method) and one that checks the values for hyphens, breaks the numbers apart, and makes sure there isn't something like two-two or twenty-thirty. So I wrapped everything into the toInt method so I would only throw one exception. My other choice was not to have the toInt method throw an exception but have the calling method (the one that process the numbers and breaks them apart if there is a hyphen and checks for odd things like two-two) throw the exception. But that goes against the rules of the assignment as the signature for the toInt method is given.
When an exception is being thrown from a method, there are two ways for a calling method to handle it: 1. catch and handle the exception using try/catch statements 2. ignore the exception and let the next calling method to handle it.
Here is an example:
For the OOP-2 assignment, what Marilyn suggests is to propagate or "bubble up" the exception to the main method to let it handles, just like methodA.
Other resources: The book "Robust Java: Exception Handling, Testing and Debugging" by Stephen Stelting provides some tips and advice on handling and designing exception. There is a tutorial on Exception by Sun.
I'm guessing that Marilyn might not want you to create a new type of exception and use that, if that's the way you went. I just submitted my first version of this assignment myself and your question got me thinking about the new type of exception that I used, and whether or not it was really needed. I went back to the program and was able to trim quite a few lines of code by just using the existing "Exception" class. I'm expecting the nit-picker to hammer me for my potentially unnecessary class, and I'll be ready with version two.
Although throwing generic Exception is quick, easy, and lowers the class count, I usually try to wrap it.
First, because I can make it more sensitive to the particular issues surrounding the exception.
Secondly, because it's easier when you're calling some sort of generalized service to be able to add in specialized logic to deal with exceptions when you can apply the instanceof operator to an exception (assuming you coded a general Exception catch) than it is to dissect the Exception message and go from there. Especially if it's an I18N message.
Exception rethrowing is often useful as well. I've done things like written parsers for reading lines in an InputStream where a bad field is tagged and thrown in an exception, then the line-processing loop catches it, adds the line number to the exception and throws it up to the caller.
Another favorite trick is chaining Exceptions when I'm constrained because I'm being called by someone whose idea of what can go wrong is limited. For example, when I'm doing callbacks for a SAX parser. They may want a SAX exception to be thrown. So I construct a SAX exception chained to the real exception. That way, we're both happy. And unlike an unchecked exception, the SAX processor isn't bypassed on the way back up, so proper SAX hygiene is preserved. [ April 13, 2005: Message edited by: Tim Holloway ]
An IDE is no substitute for an Intelligent Developer.
Marilyn de Queiroz
Joined: Jul 22, 2000
Although Tim has brought up some interesting ideas, in this case we are looking for the simplest thing that could possibly work. I think using the existing Exception class will be adequate for our purposes.