Hi, An example is a method to withdraw money from a bank account that take the amount of money to withdraw as an argument. If the withdrawal amount is bigger than current balance, we could throw an exception (probably one we made up, like BalanceNotEnoughException or something). Then the caller, which catch the exception could do something, like showing error message to the user.
When we design software components for reuse, error handling is a common concern. Susilo presents one case where throwing an exception is usable, but not really why. I'm sure you are thinking why not just check the withdraw amount and use System.out to inform the user. Problems arise when we attempt to do this. If your component is used by someone writing a braille based ATM machine, it might not even have a screen. What is that programmer to do if your module has hardcoded error handling in it? The solution is exceptions. If your component checks the incoming amount and throws an exception if there are insufficient funds, then the programmer writing the interface can choose how to handle it. He might use a sound to signal the error to the user as well as sending a message to the braille device. Think about what would happen if the Array class sent a message to the screen if the array index was out of bounds. You have an "off-by-one" error in your program. When you reach that point in the program, a message gets printed to the screen that the index is out of bounds, your code senses nothing wrong (unless it has a vision and text recognition feedback system ;-) and continues working thinking that it just successfully change that element in the array. So, exceptions exist to promote code reuse. We may not want to handle an error the same way each time. Exceptions provide the method to sense error and handle them according to the current implementation. Hope this helps.
Tom Blough<br /> <blockquote><font size="1" face="Verdana, Arial">quote:</font><hr>Cum catapultae proscriptae erunt tum soli proscripti catapultas habebunt.<hr></blockquote>
An interesting aspect of exceptions is that they can "bubble up" through many layers of method calls before they are caught. Say we have a bunch of classes and methods and A calls B and B calls C and C calls D and so on. Down in D we have some problem and throw an exception. The author of C decides he can't do anything about the problem - like maybe change some parameters and try again - so he does not catch the exception. Same for B. But up at the top in A we know that we were unable to do something the user wanted, so we catch the exception and put out a message like "That didn't work. Try something else." Contrast this with maybe checking for error codes. C might say "if (d() == -1) return -1" and B might say "if (c() == -1) return -1" and so on. That's a fair bit more code complexity, and requires us to have special return values for errors (and maybe different values for every darned method) which can be pretty limiting and confusing. Exceptions eliminate that kind of coding. Any of that makes sense?
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
posted 16 years ago
Cheers folks, I understand it now.
John Bonham was stronger, but Keith Moon was faster.
Won't you please? Please won't you be my neighbor? - Fred Rogers. Tiny ad: