Hi guys,

So I'm looking at another developers project for learning purposes and I'm just moving through the code so I can get an understanding of what's happening and how to write my own version of it. And the first thing I'm looking at is the 'try ..catch' statement. From what I can tell the purpose of try catch is to try a block of code and if an exception occurs then catch it, In this example I'm not sure how catching is actually working.

try {
            Thread.sleep(1);
        } catch (InterruptedException e) {
        }

I've also seen some basic examples where 0 is divided by a value and it's suppose to throw an Exception, the person then draws a line to say hey you can't divide like that. But in this case what will happen ?

I think more importantly, if an error occurs, does the program crash, and whether or not it crashes will I see a message in Eclipse console telling me what caused the error ? 

And then, from what I've read some peoples approach is to determine what exceptions/errors may occur and then change their code to prevent that from happening. 

These questions will help me understand whether or not I can take the following approach, code, run the program, attempt all possible interactions, when an error occurs see what it says in the console or rather see what interaction I did that caused it then modify the code to prevent that from happening, instead of catching exceptions.

Update:

I looked up exceptions a bit, I see that InterruptedException is a specific exception that throws when a sleeping thread is interrupted using the interrupt(); method. And that I don't see interrupt being used in the project then the exception is actually not required. 

Your question seems to be a little broad. Exception in general are when the program/computer encounters a situation that it does not know how to handle ie. dividing by 0. in this case, an Exception object is created and "thrown" to an Exception handler. if no exception handler is found within the program the program will exit(crash). when Designing a system a good programmer will anticipate when an exception will occur and reroute the program to prevent a crash. its important to realize that there are two types of exceptions. checked and unchecked. check exceptions are caused by programmer error and are caught by the interpreter/compiler. these types of exceptions will prevent a program from compiling. the second, uncheck, is also called a runtime error/exception. these are caused by the user giving an input that was unexpected or that the program does not know how to handle. these types are Not inherently bad. the one you are looking at may be a little confusing if you don't understand threads and concurrency. In this case the programmer has commanded a thread to wait/sleep for a certain amount of time. If in the event that some outside force like the OS, or even the user interrupts this thread it will throw an exception which the programmer can use to know that his thread is no longer sleeping. other examples of exception that are not necessarily bad; a FileNotFoundException can be used to check for the existence of a file before writing to it. after the programmer catches this exception he may, for example, prompt the user to create a new file before writing.

"In this example I'm not sure how catching is actually working." - In this example the catch doesn't have to do anything. It is just there so that the exception is handled and doesn't propagate down to the caller. Exceptions that don't get handled cause the program to terminate. So when you write code that calls a function, you need to consider whether it can throw exceptions that you need to handle - like the writer of this code did, knowing that Thread.sleep can throw InterruptedException. Note that exceptions aren't always errors, such as in this case. It's just an unusual condition that needs handling.

If you can modify code to prevent the possibillity of certain exceptions being raised, that is usually preferable. But exceptions exist to handle conditions that you can't prevent, or events that you couldn't easily predict.

Do I need to use "throws xException" in a method name, because I don't always see it used even though a try catch is used in the method ?

In Java it's useful to have that there as it forces you to write good code. If you have "throws xException" then you're not allowed to let other exceptions be thrown out of the function - which is good news for callers of that function, as they know they only ever have to handle xExceptions. This is entirely about which exceptions can be thrown out of the method - it has no relation to try/catch blocks inside the method. However, you may need to add catch blocks in order to conform to the exception specification, as you will need to handle all other exceptions.