Win a copy of Machine Learning with R: Expert techniques for predictive modeling this week in the Artificial Intelligence and Machine Learning forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Junilu Lacar
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Knute Snortum
  • Tim Cooke
  • Devaka Cooray
Saloon Keepers:
  • Ron McLeod
  • Stephan van Hulst
  • Tim Moores
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Ganesh Patekar

Throw - what's the point??

 
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.
 
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.
 
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.
 
(instanceof Sidekick)
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.
 
This is my favorite show. And this is my favorite tiny ad:
Java file APIs (DOC, XLS, PDF, and many more)
https://products.aspose.com/total/java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!