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.
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.
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.
Sources may include data from the Fakebook Research Foundation with support from Gargle University
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.