• 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 Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Rob Spoor
  • Tim Cooke
  • Junilu Lacar
Sheriffs:
  • Henry Wong
  • Liutauras Vilda
  • Jeanne Boyarsky
Saloon Keepers:
  • Jesse Silverman
  • Tim Holloway
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
Bartenders:
  • Al Hobbs
  • Mikalai Zaikin
  • Piet Souris

When to use Try and Catch

 
Ranch Hand
Posts: 55
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi

It seems to me that try and catch should be used when there is an unknown external factor that can affect things, for example when getting input streams like from sockets or files etc. However, I have seen examples where programmers use it for validation of keyboard input which could easily be handled without try and catch. What is the correct use of try and catch. Also, what should be done when the catch block variables go out scope with the try block? Netbeans warns me to use try with resources but I don't understand that.

Advice appreciated!
Toni
 
Bartender
Posts: 362
44
Firefox Browser MySQL Database Java Ubuntu
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Try / catch is used to handle cases where an exception might be thrown but you don't want it to kill your program. It's used a lot in file IO, because most operations can throw exceptions (lots of things can go wrong with reading from or writing to a file). It will help you a lot to go through the Exceptions trail of the Java Tutorials.

Try with resources allows to open a resource (like a FileReader) in a try, and will automatically close it when it exits the try, regardless of whether an exception was thrown or not. It is covered in the Java Tutorials trail above, in the The try-with-resources Statement part.
 
Saloon Keeper
Posts: 24295
167
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You use try/catch when an Exception (or at least a Throwable) is likely to be thrown. You can't catch anything unless it has been thrown somewhere.

So the real question is when to use Exceptions, along with the age-old arguments of when to use checked versus unchecked Exceptions.

There is no hard and fast rule on that and different people will choose differently. The main thing to keep in mind is that Exceptions have a relatively high level of overhead, so they are best used for situations that are, well, exceptional.

Now the nice things about exceptions are that they can short-circuit a lot of logic that won't be needed in the instance of an exception and thus hopefully keep things a little tidier and a little more reliable. Also, an Exception can carry a complex payload, so that for example, instead of returning simply true or false from an XML parser depending on whether the input was good or not, you can return the exact line number and column number as well as a detailed description of what was wrong.
 
Saloon Keeper
Posts: 8578
71
Eclipse IDE Firefox Browser MySQL Database VI Editor Java Windows
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In theory Exceptions are supposed to be used for exception situations. Validating keyboard input does not usually fall into that category BUT the old stand-by was to return some designated value (e.g. -1) to indicate an error. This had a couple of problems: a) if the call should have returned an int then -1 might have been a legitimate value, b) what to do if the caller does not add code to handle an error. An answer to that had been to  throw an exception which forces developers to write code to deal with possible errors or risk having their programs crashed. A fairly recent alternative was the introduction of the Optional class which wraps the return value so that code must be written to get to the return value and, in the process, deal with any error conditions. That's the plan, anyway. One thing that I like about the exception approach is that it offers the  opportunity for the throw-er to create a message explaining why the exception is being thrown which the call-ee can use  in error messages. I also like that the call-er is forced to deal  with the issue or die.

Note that where an exception is caught is an important consideration. If you make a call that might result in an exception being thrown you should only catch it if there's something you can do about it or it influences the next step you need to take, otherwise let it percolate up the call chain.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic