We Keep Coding

Java know in finally that exception thrown without any variable [duplicate]

In Java, is there an elegant way to detect if an exception occurred prior to running the finally block? When dealing with "close()" statements, it's common to need exception handling within the finally block. Ideally, we'd want to maintain both exceptions and propagate them up (as both of them may contain useful information). The only way I can think of to do this is to have a variable outside the try-catch-finally scope to save a reference to a thrown exception. Then propagate the "saved" exception up with any that occur in the finally block.
Is there a more elegant way of doing this? Perhaps an API call that will reveal this?
Here's some rough code of what I'm talking about:
Throwable t = null;
try {
stream.write(buffer);
} catch(IOException e) {
t = e; //Need to save this exception for finally
throw e;
} finally {
try {
stream.close(); //may throw exception
} catch(IOException e) {
//Is there something better than saving the exception from the exception block?
if(t!=null) {
//propagate the read exception as the "cause"--not great, but you see what I mean.
throw new IOException("Could not close in finally block: " + e.getMessage(),t);
} else {
throw e; //just pass it up
}
}//end close
}
Obviously, there are a number of other similar kludges that might involve saving the exception as an member variable, returning it from a method, etc... but I'm looking for something a bit more elegant.
Maybe something like Thread.getPendingException() or something similar? For that matter, is there an elegant solution in other languages?
This question actually spawned from comments in another question that raised an interesting question.

Your idea about setting a variable outside the scope of the try/catch/finally is correct.
There cannot be more than one exception propagating at once.

Instead of using a Boolean flag, I would store a reference to the Exception object.
That way, you not only have a way to check whether an exception occurred (the object will be null if no exception occurred), but you'll also have access to the exception object itself in your finally block if an exception did occur. You just have to remember to set the error object in all your catch blocks (iff rethrowing the error).
I think this is a missing C# language feature that should be added. The finally block should support a reference to the base Exception class similar to how the catch block supports it, so that a reference to the propagating exception is available to the finally block. This would be an easy task for the compiler, saving us the work of manually creating a local Exception variable and remembering to manually set its value before re-throwing an error, as well as preventing us from making the mistake of setting the Exception variable when not re-throwing an error (remember, it's only the uncaught exceptions we want to make visible to the finally block).
finally (Exception main_exception)
{
try
{
//cleanup that may throw an error (absolutely unpredictably)
}
catch (Exception err)
{
//Instead of throwing another error,
//just add data to main exception mentioning that an error occurred in the finally block!
main_exception.Data.Add( "finally_error", err );
//main exception propagates from finally block normally, with additional data
}
}
As demonstrated above... the reason that I'd like the exception available in the finally block, is that if my finally block did catch an exception of its own, then instead of overwriting the main exception by throwing a new error (bad) or just ignoring the error (also bad), it could add the error as additional data to the original error.

You could always set a boolean flag in your catch(es). I don't know of any "slick" way to do it, but then I'm more of a .Net guy.

Use logging...
try {
stream.write(buffer);
} catch(IOException ex) {
if (LOG.isErrorEnabled()) { // You can use log level whatever you want
LOG.error("Something wrong: " + ex.getMessage(), ex);
}
throw ex;
} finally {
if (stream != null) {
try {
stream.close();
} catch (IOException ex) {
if (LOG.isWarnEnabled()) {
LOG.warn("Could not close in finally block", ex);
}
}
}
}

In vb.net, it's possible to use a "Catch...When" statement to grab an exception to a local variable without having to actually catch it. This has a number of advantages. Among them:
If nothing is going to 'ultimately' catch the exception, an unhandled exception trap will be fired from the spot of the original exception. Much nicer than having the debugger trap at the last rethrow, especially since information that might be needed for debugging won't yet have gone out of scope or been swept up by 'finally' statements.
Although a rethrow won't clear the stack trace the way "Throw Ex" would, it will still often jinx the stack trace. If the exception isn't caught, the stack trace will be clean.
Because this feature is unsupported in vb, it may be helpful to write a vb wrapper to implement the code in C (e.g. given a MethodInvoker and an Action(Of Exception), perform the MethodInvoker within a "Try" and the Action in a "Finally".
One interesting quirk: it's possible for the Catch-When to see an exception which will end up getting overwritten by a Finally-clause exception. In some cases, this may be a good thing; in other cases it may be confusing. In any event, it's something to be aware of.

Is catch block able to catch Throwable (both error and exception)

In one of my interview, they asked me, is it possible to write Throwable in catch() like this
try{
some code
}
catch(Throwable t)
{
}
I said yes. it will not give a compile time error but jvm would not handle it if there occur an Error(sub class of Throwable ), since Errors are irreversible conditions that can not be handled by jvm. than they further asked than what is the use of writing Throwable .
Please give me proper reply can we use Throwable in catch. if yes why.

It is possible to catch Throwable. And yes, you will also catch instances of java.lang.Error which is a problem when it comes to e.g. OutOfMemoryError's. In general I'd not catch Throwable's. If you have to, you should do it at the highest place of your call stack, e.g. the main method (you may want to catch it, log it, and rethrow it).
I agree with your argumentation, it does not make sense to catch events you're not able to handle (e.g. OutOfMemoryError). A nice post is here.

Yes it is possible to catch Throwable.
Whether the JVM / application will be able to continue if you catch an error depends on the actual error that occurred, what caused it, and what (if anything) your application does next.
In some cases, the JVM may be in such a bad way that no recovery is possible.
In some cases, the JVM is fine ... as long as you don't do certain things. Class loading errors are a good example. If your application doesn't attempt to use the class or dependent classes that you failed to load, you should be fine to continue. (In reality, applications are not designed to continue without classes that fail to load ... but if it was, it could.)
In some cases, the core JVM will be fine, but unspecified damage could have been done to the application's data structures, and/or to its threads and computation state. OOMEs are liable to do this to you, especially if your application is not designed to deal with threads that die unexpectedly.
Catching and recovering from OOMEs is problematic for another reason. While the termination of the current computation will free up some heap space, there's a good chance that it won't free up enough space. So you can easily get into a situation where your application is repeatedly throwing and catching lots of OOMEs, and making no real progress.
All of this means that it is generally a bad idea to try to recover from errors. And that's in line with what the javadoc for error says:
"An Error is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch."

Yes we can catch Throwable but as best practice, it is not advised to catch Throwable.
Catching Throwable includes Errors too, we should not catch errors, it helps to identify JVM issues.

Throwable can be used instead of any individual exception/error. However it is recommended to pass through ThreadDeadException. So you can add extra catch clause for it, or filter by type.

Catching Throwable will catch all Exceptions (including RuntimeExceptions) and all Errors. It is not recommended to catch any of the parent Throwables (Throwable, Error, Exception or RuntimeException) but it is not uncommon to find this if a method throws too many checked exceptions or throws Exception.
It is not uncommon in certain APIs to document a method as throws Exception. This provides some flexibility at the expense of control. I like to define a new Exception class to handle this sort of case but that is personal preference.
The following simple class shows samples of the throwable types and corresponding catch blocks.
public class ThrowableExamples {
public static void main(String[] args) {
try {
// throw new NoSuchMethodException("Exception");
// throw new Exception("Exception");
// throw new IllegalStateException("RuntimeException");
// throw new RuntimeException("RuntimeException");
throw new NoSuchMethodError("Error");
// throw new Error("Error");
// throw new Throwable("Throwable");
} catch (RuntimeException e) {
System.out.println("Caught RuntimeException: " + (e.getMessage().equals("RuntimeException") ? "Expected" : "Unexpected"));
} catch (Exception e) {
System.out.println("Caught Exception: " + (e.getMessage().equals("Exception") ? "Expected" : "Unexpected"));
} catch (Error e) {
System.out.println("Caught Error: " + (e.getMessage().equals("Error") ? "Expected" : "Unexpected"));
} catch (Throwable e) {
System.out.println("Caught Throwable: " + (e.getMessage().equals("Throwable") ? "Expected" : "Unexpected"));
}
}
}

Is it a bad practice to catch Throwable?

Is it a bad practice to catch Throwable?
For example something like this:
try {
// Some code
} catch(Throwable e) {
// handle the exception
}
Is this a bad practice or we should be as specific as possible?

You need to be as specific as possible. Otherwise unforeseen bugs might creep away this way.
Besides, Throwable covers Error as well and that's usually no point of return. You don't want to catch/handle that, you want your program to die immediately so that you can fix it properly.

This is a bad idea. In fact, even catching Exception is usually a bad idea. Let's consider an example:
try {
inputNumber = NumberFormat.getInstance().formatNumber( getUserInput() );
} catch(Throwable e) {
inputNumber = 10; //Default, user did not enter valid number
}
Now, let's say that getUserInput() blocks for a while, and another thread stops your thread in the worst possible way ( it calls thread.stop() ). Your catch block will catch a ThreadDeath Error. This is super bad. The behavior of your code after catching that Exception is largely undefined.
A similar problem occurs with catching Exception. Maybe getUserInput() failed because of an InterruptException, or a permission denied exception while trying to log the results, or all sorts of other failures. You have no idea what went wrong, as because of that, you also have no idea how to fix the problem.
You have three better options:
1 -- Catch exactly the Exception(s) you know how to handle:
try {
inputNumber = NumberFormat.getInstance().formatNumber( getUserInput() );
} catch(ParseException e) {
inputNumber = 10; //Default, user did not enter valid number
}
2 -- Rethrow any exception you run into and don't know how to handle:
try {
doSomethingMysterious();
} catch(Exception e) {
log.error("Oh man, something bad and mysterious happened",e);
throw e;
}
3 -- Use a finally block so you don't have to remember to rethrow:
Resources r = null;
try {
r = allocateSomeResources();
doSomething(r);
} finally {
if(r!=null) cleanUpResources(r);
}

Also be aware that when you catch Throwable, you can also catch InterruptedException which requires a special treatment. See Dealing with InterruptedException for more details.
If you only want to catch unchecked exceptions, you might also consider this pattern
try {
...
} catch (RuntimeException exception) {
//do something
} catch (Error error) {
//do something
}
This way, when you modify your code and add a method call that can throw a checked exception, the compiler will remind you of that and then you can decide what to do for this case.

straight from the javadoc of the Error class (which recommends not to catch these):
* An <code>Error</code> is a subclass of <code>Throwable</code>
* that indicates serious problems that a reasonable application
* should not try to catch. Most such errors are abnormal conditions.
* The <code>ThreadDeath</code> error, though a "normal" condition,
* is also a subclass of <code>Error</code> because most applications
* should not try to catch it.
* A method is not required to declare in its <code>throws</code>
* clause any subclasses of <code>Error</code> that might be thrown
* during the execution of the method but not caught, since these
* errors are abnormal conditions that should never occur.
*
* #author Frank Yellin
* #version %I%, %G%
* #see java.lang.ThreadDeath
* #since JDK1.0

It's not a bad practice if you absolutely cannot have an exception bubble out of a method.
It's a bad practice if you really can't handle the exception. Better to add "throws" to the method signature than just catch and re-throw or, worse, wrap it in a RuntimeException and re-throw.

Catching Throwable is sometimes necessary if you are using libraries that throw Errors over-enthusiastically, otherwise your library may kill your application.
However, it would be best under these circumstances to specify only the specific errors thrown by the library, rather than all Throwables.

The question is a bit vague; are you asking "is it OK to catch Throwable", or "is it OK to catch a Throwable and not do anything"? Many people here answered the latter, but that's a side issue; 99% of the time you should not "consume" or discard the exception, whether you are catching Throwable or IOException or whatever.
If you propagate the exception, the answer (like the answer to so many questions) is "it depends". It depends on what you're doing with the exception—why you're catching it.
A good example of why you would want to catch Throwable is to provide some sort of cleanup if there is any error. For example in JDBC, if an error occurs during a transaction, you would want to roll back the transaction:
try {
…
} catch(final Throwable throwable) {
connection.rollback();
throw throwable;
}
Note that the exception is not discarded, but propagated.
But as a general policy, catching Throwable because you don't have a reason and are too lazy to see which specific exceptions are being thrown is poor form and a bad idea.

Throwable is the base class for all classes than can be thrown (not only exceptions). There is little you can do if you catch an OutOfMemoryError or KernelError (see When to catch java.lang.Error?)
catching Exceptions should be enough.

it depends on your logic or to be more specific to your options / possibilities. If there is any specific exception that you can possibly react on in a meaningful way, you could catch it first and do so.
If there isn't and you're sure you will do the same thing for all exceptions and errors (for example exit with an error-message), than it is not problem to catch the throwable.
Usually the first case holds and you wouldn't catch the throwable. But there still are plenty of cases where catching it works fine.

Although it is described as a very bad practice, you may sometimes find rare cases that it not only useful but also mandatory. Here are two examples.
In a web application where you must show a meaning full error page to user.
This code make sure this happens as it is a big try/catch around all your request handelers ( servlets, struts actions, or any controller ....)
try{
//run the code which handles user request.
}catch(Throwable ex){
LOG.error("Exception was thrown: {}", ex);
//redirect request to a error page.
}
}
As another example, consider you have a service class which serves fund transfer business. This method returns a TransferReceipt if transfer is done or NULL if it couldn't.
String FoundtransferService.doTransfer( fundtransferVO);
Now imaging you get a List of fund transfers from user and you must use above service to do them all.
for(FundTransferVO fundTransferVO : fundTransferVOList){
FoundtransferService.doTransfer( foundtransferVO);
}
But what will happen if any exception happens? You should not stop, as one transfer may have been success and one may not, you should keep go on through all user List, and show the result to each transfer. So you end up with this code.
for(FundTransferVO fundTransferVO : fundTransferVOList){
FoundtransferService.doTransfer( foundtransferVO);
}catch(Throwable ex){
LOG.error("The transfer for {} failed due the error {}", foundtransferVO, ex);
}
}
You can browse lots of open source projects to see that the throwable is really cached and handled. For example here is a search of tomcat,struts2 and primefaces:
https://github.com/apache/tomcat/search?utf8=%E2%9C%93&q=catch%28Throwable
https://github.com/apache/struts/search?utf8=%E2%9C%93&q=catch%28Throwable
https://github.com/primefaces/primefaces/search?utf8=%E2%9C%93&q=catch%28Throwable

Generally speaking you want to avoid catching Errors but I can think of (at least) two specific cases where it's appropriate to do so:
You want to shut down the application in response to errors, especially AssertionError which is otherwise harmless.
Are you implementing a thread-pooling mechanism similar to ExecutorService.submit() that requires you to forward exceptions back to the user so they can handle it.

Throwable is the superclass of all the errors and excetions.
If you use Throwable in a catch clause, it will not only catch all exceptions, it will also catch all errors. Errors are thrown by the JVM to indicate serious problems that are not intended to be handled by an application. Typical examples for that are the OutOfMemoryError or the StackOverflowError. Both are caused by situations that are outside of the control of the application and can’t be handled. So you shouldn't catch Throwables unless your are pretty confident that it will only be an exception reside inside Throwable.

If we use throwable, then it covers Error as well and that's it.
Example.
public class ExceptionTest {
/**
* #param args
*/
public static void m1() {
int i = 10;
int j = 0;
try {
int k = i / j;
System.out.println(k);
} catch (Throwable th) {
th.printStackTrace();
}
}
public static void main(String[] args) {
m1();
}
}
Output:
java.lang.ArithmeticException: / by zero
at com.infy.test.ExceptionTest.m1(ExceptionTest.java:12)
at com.infy.test.ExceptionTest.main(ExceptionTest.java:25)

A more differentiated answer would be: it depends.
The difference between an Exception and an Error is that an Exception is a state that has to be expected, while an Error is an unexpected state, which is usually fatal. Errors usually cannot be recovered from and require resetting major parts of the program or even the whole JVM.
Catching Exceptions is something you should always do to handle states that are likely to happen, which is why it is enforced by the JVM. I.E. opening a file can cause a FileNotFoundException, calling a web resource can result in a TimeoutException, and so on. Your code needs to be prepared to handle those situations as they can commonly occur. How you handle those is up to you, there is no need to recover from everything, but your application should not boot back to desktop just because a web-server took a little longer to answer.
Catching Errors is something you should do only if it is really necessary. Generally you cannot recover from Errors and should not try to, unless you have a good reason to. Reasons to catch Errors are to close critical resources that would otherwise be left open, or if you i.E. have a server that runs plugins, which can then stop or restart the plugin that caused the error. Other reasons are to log additional information that might help to debug that error later, in which case you of course should rethrow it to make sure the application terminates properly.
Rule of thumb: Unless you have an important reason to catch Errors, don't.
Therefore use catch (Throwable t) only in such really important situation, otherwise stick to catch (Exception e)

How to effectively handle any kind of exceptions?

Exception handling is the most useful mechanism to save the application from the crash. Even most of us following the exception handling mechanism. Even I see many of still getting the exceptions. Are we handling the exceptions in a way that supposed to? My question is, What is best way to handle any kind of exception?
I want to make few things clear. When I say handling an exception that does not only mean that capturing appropriate exception message and showing or logging it. Rather, it suppose to handle corrective action for exception.
Lets consider this piece of code:
try {
someMethod1();
} catch (MyException e) {
System.out.println(e.getMessage());
} catch (YourException e) {
System.out.println(e.getMessage());
}
In the above code, "MyException" and "YourException" may not catch all kind of Exception. But, of course we can use "java.lang.Exception". How would we identify the correct exception type? and how to handle that exception? especially when using external libraries.
More detail upon request.
Thanks

You do not want to capture Runtime exceptions. The reason being, you are just hiding a bug right there. Instead let the application fail and fix it. To answer to your questions, if you catch Throwable, you are going to basically eat up any kind of exceptions.
Rule of thumb: Only catch application exception.

I don't know if I'm actually getting the meaning of your question, but, you can catch as many expceptions as you need at a certain block of code:
try {
someMethod1();
} catch (MyException e) {
System.out.println(e.getMessage());
} catch (YourException e) {
System.out.println(e.getMessage());
} catch (IOException e) {
//handle
} catch (SQLException e) {
//handle
}
And, based on exception hierarchy, when you catch a exception, you are also catching every subtype of this exception, so, when you need to catch every unexpected error condition, you can add a catch for java.lang.Exception (at the last catch statement)
try {
someMethod1();
} catch (MyException e) {
System.out.println(e.getMessage());
} catch (YourException e) {
System.out.println(e.getMessage());
} catch (Exception e) {
//handle generic unexpected exception
}
You could also catch the super interface Throwable, but it's not recommended, as the only difference is that, aside the exceptions, you will catch the Errors too. The errors are fatal conditions, which should not be handled, as they use to mean serious problems at the java VM, as Out of Memory, Stack Overflow, etc.
These links can be useful on how to handle java Exceptions:
http://download.oracle.com/javase/tutorial/essential/exceptions/index.html
http://tutorials.jenkov.com/java-exception-handling/index.html
Regards.

Guys from Software Engineering Radio podcast had two very good episodes on Error Handling.

If you really want to catch every possible exception, catching Throwable is what you want to do:
try {
somethingThatMayFail();
} catch (Throwable t) {
t.printStackTrace();
}
More often than not, this is a bad idea, though. You shouldn't catch any exceptions if you don't know why they occurred, or how to clean up after them. Not crashing is not necessarily a good thing - if your program is broken, crashing is the responsible thing to do. Consider this method:
public Thing loadThing(long id){
try {
return doLoad(id);
} catch (Throwable t) {
// What do we do here?
}
}
The compiler forces you to return or throw something from every possible execution path of the method, but only the non-exceptional path allows us to return something sensible. We could return null from the catch clause, but then the calling code might forget checking the return value for null, which means you'll instead end up with a NullPointerException which is far harder to decipher since it doesn't tell you what the real error was or where it occurred.
Exceptions are good. There are reasons why every sensible language has them.

The type of any object can be inspected via reflection. But i don't like using it much.
try {
throw new Exception1();
} catch (Throwable t) {
// just get name
System.out.println(t.getClass().getName() + " caught");
// or try instanceof - this is not nice approach IMO
if (t instanceof Exception1) {
System.out.println("yes exception1");
}
}
BTW did think or heard about AOP? To be more precise about AspectJ. Aspect oriented programming can be answer to your question how to print or log exceptions while your code is still clean and easily maintainable. If you are using Java EE and EJB, you can try interceptors mechanism instead of AspectJ. I recommend you read something about AOP and AspectJ (for Java).
cheers

It sounds like you're trying to figure out how to know when you've handled every possible exception. If you just don't put a throws clause on your method then the compiler will tell you which exceptions you need to put handlers for.

If you are using Eclipse, one way is to write the code with out exception handling and it will make you see the types of exceptions that your code might throw.
If you want your program sequence to continue as you have coded, then you can surround only that part of code that might throw an exception and in the Catch block perform necessary steps so that your program works in the flow you want.
something like
"
code ...
try{
something....
}catch(someException e){
// handle it
}
try{
something....
}catch(someException e){
// handle it
}
code ...
"
However this code does not catch any exception that may occur otherwise (i.e, not because of your code). For that an Outer Try Catch might help you find out that it was something else
like
"
try
{
code ...
try{
something....
}catch(someException e){
// handle it
}
try{
something....
}catch(someException e){
// handle it
}
code ...
}
catch(runtime e){
//tell user/log that something unexpected has occured
}
"

Your code is correct. If someMethod1() method does not declare any other Exceptions, they are RuntimeExceptions and you are supposed to catch RuntimeException.

How do I add state information without writing repetitive code when catching multiple Java exceptions?

I've read a few other posts like this one about avoiding repetition in Java catch blocks. Apparently, what I really want is "multi-catch", but seeing as Java 7 isn't here yet, is there a good pattern to let me add state to my exceptions, then re-throw them, without catching the kitchen sink?
Specifically, I have some code that makes library calls, which can throw exceptions, but don't provide nearly enough context for successful debuging. I find myself having a problem, then going in, wrapping the library call in a try/catch, catching the specific exception, then adding extra state information in the catch block and re-throwing the caught exception. I then re-iterate through that loop over and over, each time finding a new error condition to log. I wind up with
try {
make_library_call();
}
catch (SomeException e){
throw new SomeException ("Needed local state information is " + importantInfo, e);
}
catch (SomeOtherException e){
throw new SomeOtherException ("Needed local state information is " + importantInfo, e);
}
catch (YetAnotherException e){
throw new YetAnotherException ("Needed local state information is " + importantInfo, e);
}
etc etc. I think what I'd really like to see is more along the lines of
try {
make_lib_call();
}
catch(Exception e){
e.AddSomeInformationSomehow("Needed Info" + importantInfo);
throw e;
}
assuming that in that case e would keep its actual runtime type when re-thrown -- in this case, even catching unchecked would probably be OK since I'd be re-throwing them, and they'd benefit from carrying the extra state info as well. I guess an alternate might be something like
try{
make_lib_call();
}
finally {
if (/*an exception happened*/)
logger.debug("Some state info: " + importantInfo);
}
but I don't know how to write the conditional. Is that crazy / wrong?

You're probably expecting this, but no, there isn't a good (and by good I mean clean) way to do this. You're probably expecting it because you subconsciously knew that if there was a good pattern for doing this, it probably wouldn't have been worth adding to Java 7.
It's actually the final rethrow feature that you'd find really handy in this case.

For the alternative:
boolean isOk = false;
try{
make_lib_call();
isOk = true;
}
finally {
if (!isOk)
logger.debug("Some state info: " + importantInfo);
}