• Post Reply Bookmark Topic Watch Topic
  • New Topic

Throw - what's the point??  RSS feed

 
Steve Jensen
Ranch Hand
Posts: 126
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Folks, i've typed in a small program which makes use of the 'throw' keyword.
The code is shown below:-


But my query is, why would we want to deliberately throw an exception explicitly???
Cheers in advance.
 
Susilo Saja
Ranch Hand
Posts: 91
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Tom Blough
Ranch Hand
Posts: 263
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
Steve Jensen
Ranch Hand
Posts: 126
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Cheers folks, I understand it now.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!