[Armen]: an Error indicates that a non-recoverable error has occurred that should not be caught. Yes, that's the company line. But frankly, it's not true. At the very least, if you're using some sort of logging, it's often useful for your top-level methods to do something like this:
In many cases you'd also rethrow t after logging. But that's pointless here. The main idea though is to ensure that wherever your main logging is going (e.g. a log file), you want the error report to go there too. You don't want the log file to contain everything
but the stack trace, which instead appeared in stderr. That would be poor planning.
Additionally, some Errors really
are recoverable, no matter what anyone else says. OutOfMemoryError is a good example. Sure, it means that it was impossible to complete the original requested action. But that doesn't mean the rest of the application can't continue to function. As an example, say I'm writing a search engine. Most searches return less than ten results, and that's great. Some searches return millions of results, and that results in an OOME. OK, so that means that certain searches are not possible. So you catch the OOME at a high level, and tell the user that the search is not possible. But that's no reason to crash the whole search engine. You may still have
plenty of memory available - you just don't have enough for
some very large resultsets. So it makes perfect sense to catch an Error in this case and deal with it rationally rather than base fear.
I would say that anytime you're dealing with an Error,
you should think carefully about what you're doing. Moreso than for an Exception, usually. But blindly saying "Errors should not be caught" is too simple-minded a rule to be of use to anyone but a beginner. The real world is more complex than that.
[ February 04, 2007: Message edited by: Jim Yingst ]