It will be worth reading a Java book, and I hope I have followed the strategy closely. In simple terms, when something unexpected happens (e.g. divide by zero) the programmer can anticipate it and 'throw an exception' - there can be as many types of exception as you like - they are all objects - and they can have hierarchies where it helps. (For example, I have several Matrix exceptions which are all subclasses of IllConditionedMatrix). This exception has to be 'caught' somewhere, either in the calling module, or somewhere higher up in the calling stack. If it isn't caught, it gives a stack dump and may or may not halt program execution.
Exceptions can proliferate throughout code and can appear very tedious. However, they are always telling you that at this point, something could go wrong, and it you put off dealing with it, it won't go away! It's tempting to ignore exceptions and (say) set a variable to a default value, but this could be catastrophic! If you take them seriously, they may tell you something about the structure of your application.
When you compile (javac) an *.java file it may tell you that something throws an exception and you must trap this. For example, suppose you call a standard deviation routine in DMUnivariate, you will get a compile error requiring you to trap an ArrayTooSmall exception. This will occur if you only have one data point - where standard deviation is meaningless! So - although it may not be likely - trap this and do something about it.
Good luck!
PeterMR, July 1996.