This is the code sample and I am getting an error "must be caught or declare to
be thrown" but I have
already handled the IOException. So can you please tell why the error is populating. The code also
follows the handle and declare rule.
public void rethrow() throws SQLException, IOException {
try {
couldThrowAnException();
}
catch(Exception e) {
e = new IOException();
throw e; //Error: must be caught or declare to be thrown
}
}
The problem you are running into is that the compiler deals with the variable declaration type, not the type you assign to the variable.
The variable is of type Exception, which is not part of the throws clause.
If you change the catch() clause to match IOException, it will compile.
I'd suggest you read the Exceptions Trail of the Java Language Tutorial.
You handled IOException but you are throwing Exception(not IOException ) from catch block.
So you have to add Exception in throws clause
or
catch IOException instead of Exception in the catch block
public void rethrow() throws SQLException, IOException {
try {
couldThrowAnException();
}
catch(IOException e) {
e = new IOException();
throw e; //Error: must be caught or declare to be thrown
}
}
Although, it makes no sens to cathc it and throw it...
A far better way would be:
public void rethrow() {
try {
couldThrowAnException();
}
catch(IOException e) {
//do something when you encounter the io-error
}
catch(SQLException e) {
//do something when you encounter the sql-error
}
}
Related
I am trying to understand suppressed Exceptions in Java SE7, I posted 2 examples below, They are similar, In the following example, I was under the impression that when new "main Exception" happens, the suppressed ones get ignored, for instance I was expecting the output to be "java.lang.RuntimeException: y", However the answer is:
java.lang.RuntimeException: y
suppressed java.lang.RuntimeException: a
Here is the code:
class Animal implements AutoCloseable{
#Override
public void close() {
throw new RuntimeException("a");
}
}
public class ExceptionsDemo {
public static void main(String[] args) throws IOException {
try(Animal a1 = new Animal();){
foo();
}
catch(Exception e){
System.err.println(e);
for(Throwable t : e.getSuppressed()){
System.err.println("suppressed "+ t);
}
}
}
static void foo() {
try {
throw new RuntimeException("x");
} catch (Exception e) {
throw new RuntimeException("y");
}
}
}
My understanding was that after tryWithResources clause, "a" is main Exc, then in foo(), x becomes main exc while a gets suppressed, but in catch, I thought y will become the solo main exc and will ignore all other exceptions including suppressed ones? Like this second example, It does what I just mentioned, it outputs java.lang.RuntimeException: c with no suppressed exceptions.
public class ExceptionDemo2 {
class Animal implements AutoCloseable{
#Override
public void close() {
throw new RuntimeException("a");
}
}
public static void main(String[] args) {
try{
new ExceptionDemo2().go();
}
catch(Exception e){
System.err.println(e);
for(Throwable t : e.getSuppressed()){
System.err.println("suppressed "+ t);
}
}
}
void go(){
try(Animal a = new Animal()){
throw new IOException();
}catch(Exception e){
throw new RuntimeException("c");
}
}
}
output: java.lang.RuntimeException: c
Your example
try(Animal a1 = new Animal();){
foo();
}
catch(Exception e){
System.err.println(e);
for(Throwable t : e.getSuppressed()){
System.err.println("suppressed "+ t);
}
}
terminates because foo() throws a RuntimeException (y). That's the target of the catch. Because execution leaves the try block, all declared resources are closed. While closing the Animal instance, another RuntimeException (a) is thrown. That one is suppressed because it wasn't the root cause.
The translation of try-with-resources to a try-catch-finally block is explained in the JLS, here.
The meaning of a basic try-with-resources statement:
try ({VariableModifier} R Identifier = Expression ...)
Block
is given by the following translation to a local variable declaration
and a try-catch-finally statement:
{
final {VariableModifierNoFinal} R Identifier = Expression;
Throwable #primaryExc = null;
try ResourceSpecification_tail
Block
catch (Throwable #t) {
#primaryExc = #t;
throw #t;
} finally {
if (Identifier != null) {
if (#primaryExc != null) {
try {
Identifier.close();
} catch (Throwable #suppressedExc) {
#primaryExc.addSuppressed(#suppressedExc);
}
} else {
Identifier.close();
}
}
}
}
where
If the resource specification declares one resource, then
ResourceSpecification_tail is empty (and the try-catch-finally
statement is not itself a try-with-resources statement).
Your code above basically translates to something like
try {
final Animal a1 = new Animal();
Throwable thr = null;
try {
foo();
} catch (Throwable root) {
thr = root;
throw root;
} finally {
if (a1 != null) {
if (thr != null) {
try {
a1.close();
} catch (Throwable suppressed) {
thr.addSuppressed(suppressed); // <<<<<< suppressing the failure of 'close'
}
} else {
a1.close();
}
}
}
} catch (Exception e) {
System.err.println(e);
for (Throwable t : e.getSuppressed()) {
System.err.println("suppressed " + t);
}
}
This is confusing because it mixes try-with-resources with the exception-masking behavior that try-with-resources is supposed to cure.
Also it seems like you're not aware of what it means for an exception to be suppressed. Suppressed means that the exception is tacked on to an existing exception, rather than being thrown, and in the progress causing the exception thrown within the try-block getting lost (the usual term is "masked").
Exception-masking means that an exception thrown from the finally or catch block results in any exception thrown from within the try block getting discarded. Since the exceptions thrown on in the try-blocks are usually descriptive of what your error is, and the exceptions thrown on close are usually uninteresting, this is a bad thing; try-with-resources was created in order to try to reduce the prevalence of this problem.
So in your first example, foo is called on a1 within the try block, within foo the exception thrown within the catch, y, masks the exception thrown in foo's try block. Then when the try-with-resources block is exited the close method is called and the exception thrown on close gets added onto the y exception that is in-flight. So your printlns show y, then iterate through the suppressed exceptions attached to y.
In the second example, c is what's thrown from the go method (it's the same masking behavior described above). The IOException in the go method try block got thrown, the close method was called on the way out, causing the exception on close to get added to the IOException as a suppressed exception, then the IOException gets masked by c. Because a got masked, and the suppressed exception was attached to a, we lose the suppressed exception too. The c exception thrown on close has no suppressed exceptions associated with it because it was generated after the try-with-resources block was exited.
From the Oracle documentation http://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html:
If an exception is thrown from the try block and one or more exceptions are thrown from the try-with-resources statement, then those exceptions thrown from the try-with-resources statement are suppressed. You can retrieve these suppressed exceptions by calling the Throwable.getSuppressed method from the exception thrown by the try block.
So as expected the first example gives the output:
java.lang.RuntimeException: y
suppressed java.lang.RuntimeException: a
In the second code snippet also there is a case of Exception Suppression. To validate that I have modified your function as:
void go() {
try (Animal a = new Animal()) {
throw new IOException();
} catch (Exception e) {
for (Throwable t : e.getSuppressed()) {
System.err.println("suppressed " + t);
}
throw new RuntimeException("c");
}
}
Then the output will be:
suppressed java.lang.RuntimeException: a
java.lang.RuntimeException: c
I have encountered a scenario while working with exceptions, following is the sample code.I am trying to understand why following code fails to compile. I am checking the exception type before rethrow which is unchecked exception.
public class TestException {
public void test() throws FileNotFoundException {
FileReader test = new FileReader("");
}
public static void main(String[] args){
TestException test=new TestException();
try {
test.test();
} catch (Exception e) {
// TODO Auto-generated catch block
if(e instanceof ArithmeticException){
throw e;
}
else{
e.printStackTrace();
}
}
}
}
You are still throwing a reference variable e of type Exception. Exception is a checked type. The compiler only knows the reference variable's type, not the referenced object's. If you want to keep main's method signature as-is, you'll need to either wrap e into an unchecked exception type (such as ArithmeticException):
if(e instanceof ArithmeticException){
throw new ArithmeticException(e.getMessage());
}
or cast it as an unchecked exception:
if(e instanceof ArithmeticException){
throw (ArithmeticException)e;
}
Since the reference variable e is of type java.lang.Exception, throw e will throw checked exception. Thus it has to be declared in throws section in the method signature.
Try changing your catch block as follows:-
if(e instanceof ArithmeticException){
throw (ArithmeticException)e;
}
else{
e.printStackTrace();
}
You could also use a hack with Generics to throw an checked Exception as an unchecked one:
http://www.gamlor.info/wordpress/2010/02/throwing-checked-excpetions-like-unchecked-exceptions-in-java/
I like to use this over throw new RuntimeException(e), since the latter creates unnecessary output in a Stacktrace and its harder to catch somewhere else (you have to check the cause instead of the excetion itself).
catch (Exception e) {
Here is the effective declaration of e.
if(e instanceof ArithmeticException){
Here you are doing a runtime check of the type of e.
throw e;
At this point the compile-time type of e is Exception. So the compiler enforces its rules.
I will suggest to use two catch blocks.
typechecking in catch block is not a good practice where you can catch that specific class using other catch statement.
catch (ArithmeticException e) {
// TODO Auto-generated catch block
throw e;
}
catch(Exception e)
{
e.printStackTrace();
}
#Silly Freak I agree with you.
If you throw any exception then you should handle it but in your program your are able to throw but nowhere you are handling the exception, so just handle the exception by adding throws in main class like this:-
package first;
import java.io.FileNotFoundException;
import java.io.FileReader;
class A3{
public void test() throws FileNotFoundException {
FileReader test = new FileReader("");
}
public static void main(String[] args) throws Exception{
A3 test=new A3();
try {
test.test();
} catch (Exception e) {
// TODO Auto-generated catch block
if(e instanceof ArithmeticException){
throw e;
}
else{
e.printStackTrace();
}
}
}
}
import java.io.*;
class West1 extends Exception {
private String msg;
public West1() {
}
public West1(String msg) {
super(msg);
this.msg=msg;
}
public West1(Throwable cause) {
super(cause);
}
public West1(String msg,Throwable cause) {
super(msg,cause);
this.msg=msg;
}
public String toString() {
return msg;
}
public String getMessage() {
return msg;
}
}
public class West {
public static void main(String[] args) {
try {
throw new West1("Custom Exception.....");
}catch(West1 ce) {
System.out.println(ce.getMessage());
//throw new NumberFormatException();
throw new FileNotFoundException();
}catch(FileNotFoundException fne) {
fne.printStackTrace();
}/*catch(NumberFormatException nfe) {
nfe.printStackTrace();
}*/
}
}
In the above code, NumberFormatException is thrown from catch block it compile and run successfully but when FileNotFoundException is thrown from catch block it will not compile. Following Errors are thrown:
West.java:40: error: exception FileNotFoundException is never thrown in body of
corresponding try statement
}catch(FileNotFoundException fne){
West.java:39: error: unreported exception FileNotFoundException; must be caught
or declared to be thrown
throw new FileNotFoundException();
So my question is what is reason behind this behaviour?
NumberFormatException is a RuntimeException, meaning that it's not required to be declared in all methods it may be thrown. This means that, unlike FileNotFoundException, the compiler can not know if it can get thrown in a block or not.
The title implies you are trying to catch multiple exceptions at once, and your code implies you understand that you can have multiple catch blocks for a single try block to catch different types of exceptions. Everything is good so far, but you seem to misunderstand exactly where the try-catch catches errors.
Here is you code. I removed the comments to make it more concise.
public class West {
public static void main(String[] args) {
try {
throw new West1("Custom Exception.....");
} catch(West1 ce) {
System.out.println(ce.getMessage());
throw new FileNotFoundException(); // <-- Must be caught
} catch(FileNotFoundException fne) { // <-- Never thrown
fne.printStackTrace();
}
}
}
The first compiler error is because the catch block that is for catching FileNotFoundException's try block never throws FileNotFoundException. The second compiler error is because FileNotFoundException is a checked exception. Because it is a checked exception your code must either
handle it (by catching it with try-catch)
let everyone know it could throw it (public static void main(String[] args) throws FileNotFoundException { ...).
From the context of your code, you seem to be going with the first option, handling it with try-catch, but you have the catch in the wrong place.
catch blocks don't catch exceptions, try blocks do. catch blocks specify what to do with the actual caught exception.
public class West {
public static void main(String[] args) {
try {
throw new West1("Custom Exception.....");
} catch(West1 ce) {
System.out.println(ce.getMessage());
try {
throw new FileNotFoundException();
} catch(FileNotFoundException fne) {
fne.printStackTrace();
}
}
}
}
Try that instead. Notice how you can have a try instead of a catch. This wouldn't matter if FileNotFoundException wasn't a checked exception.
I have been trying to find out answer to this question but did not get any satisfactory explanation. Here is some background:
Java 7 allows us to catch multiple exceptions in a single catch block provided those exceptions are from diffrent hierarchy. Eg:
try {
// some code
} catch(SQLException | FileNotFoundException e) {
e.printStackTrace();
} catch(Exception e) {
e.printStackTrace();
}
But if exceptions are from the same hierarchy we must use multiple catch blocks like:
try {
// some code
} catch(FileNotFoundException e) {
e.printStackTrace();
} catch(IOException e) {
e.printStackTrace();
}
But if I try to write code like below compiler complains that "The exception FileNotFoundException is already caught by the alternative IOException"
try {
// some code
} catch(FileNotFoundException | IOException e) { // compiler error
e.printStackTrace();
}
Now my question is: Why compiler reports an error in last case, can't it figure out that FileNotFoundException is special case of IOException? This would save code duplication when my exception handling logic is same.
Why compiler reports an error in last case, can't it figure out that FileNotFoundException is special case of IOException?
Because FileNotFoundException is a subclass of IOException. In other words, the "FileNotFoundException |" part is redundant.
The reason why the code below is ok...
} catch(FileNotFoundException e) {
...
} catch(IOException e) {
...
}
...is because here the IOException clause matters: If a SocketException is thrown for instance, it will pass the by the FileNotFoundException part, and get caught in the IOException clause.
When catching an exception you have order your catch clauses from the most specific to the most general.
Consider the following hierachy:
class MyException extends Exception {}
class MySubException extends MyException {}
If a part of your code throws MyException an an other part throws MySubException you have to catch MySubException first.
catch(MySubException e){
} catch(MyException e){
}
Its the same thing like using the instanceof operator.
If you test if an instance of MySubException is an instanceof MyException the result will be true.
mse = new MySubException();
if(mse instanceof MyException){
println("MyException");
} else if(mse instanceof MySubException){
println("MySubException");
}
This piece of code will never print "MySubException".
mse = new MySubException();
if(mse instanceof MySubException){
println("MySubException");
} else if(mse instanceof MyException){
println("MyException");
}
This would be the correct order.
Its because FileNotFoundException extends IOException, as you said its of same hierarchy, you cannot add them to same catch block.
This question already has answers here:
Close resource quietly using try-with-resources
(4 answers)
Closed 1 year ago.
I was reading about the try-with-resource in JDK7 and while I was thinking of upgrading my application to run with JDK7 I faced this problem..
When using a BufferedReader for example the write throws IOException and the close throws IOException.. in the catch block I am concerned in the IOException thrown by the write.. but I wouldn't care much about the one thrown by the close..
Same problem with database connections.. and any other resource..
As an example I've created an auto closeable resource:
public class AutoCloseableExample implements AutoCloseable {
public AutoCloseableExample() throws IOException{
throw new IOException();
}
#Override
public void close() throws IOException {
throw new IOException("An Exception During Close");
}
}
Now when using it:
public class AutoCloseTest {
public static void main(String[] args) throws Exception {
try (AutoCloseableExample example = new AutoCloseableExample()) {
System.out.println(example);
throw new IOException("An Exception During Read");
} catch (Exception x) {
System.out.println(x.getMessage());
}
}
}
how can I distinguish between such exceptions without having to create wrappers for classes such as BufferedReader?
Most of cases I put the resource close in a try/catch inside the finally block without caring much about handling it.
Lets consider the class:
public class Resource implements AutoCloseable {
public Resource() throws Exception {
throw new Exception("Exception from constructor");
}
public void doSomething() throws Exception {
throw new Exception("Exception from method");
}
#Override
public void close() throws Exception {
throw new Exception("Exception from closeable");
}
}
and the try-with-resource block:
try(Resource r = new Resource()) {
r.doSomething();
} catch (Exception ex) {
ex.printStackTrace();
}
1. All 3 throw statements enabled.
Message "Exception from constructor" will printed and the exception thrown by constructor will be suppressed, that means you can't catch it.
2. The throw in constructor is removed.
Now the stack trace will print "Exception from method" and "Suppressed: Exception from closeable" below. Here you also can't catch the suppressed exception thrown by close method, but you will be nofitied about the suppressed exception.
3. Throws from constructor and method are removed.
As you have probably already guessed the "Exception from closeable" will be printed.
Important tip: In all of above situations you are actually catching all exceptions, no matter where they were throwed. So if you use try-with-resource block you don't need to wrap the block with another try-catch, the extra block is simply useless.
Hope it helps :)
I would suggest using a flag as in the following example:
static String getData() throws IOException {
boolean isTryCompleted = false;
String theData = null;
try (MyResource br = new MyResource();) {
theData = br.getData();
isTryCompleted = true;
} catch(IOException e) {
if (!isTryCompleted )
throw e;
// else it's a close exception and it can be ignored
}
return theData;
}
source:Close resource quietly using try-with-resources