"All errors and exceptions extend from Throwable. By catching Throwable, it is possible to handle all unexpected conditions.

There are several scenarios where it is good practice to catch Throwable. For example, in a server application, the threads that handle requests should catch Throwable and relay any errors or exceptions to the client. Another scenario is a long-running thread that performs some background activity. Such threads should catch Throwable, log any errors or exceptions, and then continue functioning.

It is rarely good practice for a method in a library to catch Throwable. In general, errors and exceptions should not be masked from the caller."

Answered by Dayananda , an ibibo Advisor, at 2:52 PM on January 15, 2008

The organizational difference is needed because of the ways the different types need to be handled. Errors and the classes that derive from the Error class result from errors inside the system, such as lack of memory or some other error beyond your control. The idea in these instances is just to keep your program from crashing hard and simply to exit cleanly or figure a way around the problem. For this reason, your programming will not have to deal with these thrown Errors, because they usually are implemented by other classes that make sure those kind of errors don't occur and are handled nicely (instead of, for example, locking up the machine or crashing the operating system). In other words, you don't need to worry about handling OutofMemoryErrors, StackOverflowErrors and so on; they generally already are handled for you.

Answered by ayisha , an ibibo Master, at 2:57 PM on January 13, 2008

Java Almanac has a good summary.
See http://javaalmanac.com/egs/Java%20L anguage/CatchThrowable.html?l=new
"All errors and exceptions extend from Throwable. By catching Throwable, it is possible to handle all unexpected conditions.
There are several scenarios where it is good practice to catch Throwable. For example, in a server application, the threads that handle requests should catch Throwable and relay any errors or exceptions to the client. Another scenario is a long-running thread that performs some background activity. Such threads should catch Throwable, log any errors or exceptions, and then continue functioning.
It is rarely good practice for a method in a library to catch Throwable. In general, errors and exceptions should not be masked from the caller."

Answered by Nz , an ibibo Master, at 2:14 AM on January 13, 2008