Is it meaningful to declare a method to throw an exception
and a subclass of this exception,
e.g. IOException and FileNotFoundException?
I guess that it is used in order to handle both exceptions by a caller method differently.
However, is it possible to handle both exceptions if the method throws only the most generic i.e IOException?
However, is it possible to handle both exceptions if the method throws only the most generic i.e IOException?
Absolutely. You can still catch them separately:
try {
methodThrowingIOException();
} catch (FileNotFoundException e) {
doSomething();
} catch (IOException e) {
doSomethingElse();
}
So it makes no difference to what the caller can do if the method declares both - it's redundant. However, it can emphasize exceptions that you might want to consider. This could be done better in Javadoc than just the throws declaration.
Is it meaningful to declare a method to throw an exception and a subclass of this exception, e.g. IOException and FileNotFoundException?
Usually not - most IDEs I know of even issue warnings for such declarations. What you can and should do is to document the different exceptions thrown in Javadoc.
However, is it possible to handle both exceptions if the method throws only the most generic i.e IOException?
Yes it is, you just need to ensure that the catch blocks are in the right order, i.e. more specific first. Catch blocks are evaluated in the order they are defined, so here
try {
...
} catch (FileNotFoundException e) {
...
} catch (IOException e) {
...
}
if the exception thrown is a FileNotFoundException, it will be caught by the first catch block, otherwise it will fall to the second and dealt with as a general IOException. The opposite order would not work as catch (IOException e) would catch all IOExceptions including FileNotFoundException. (In fact, the latter would result in a compilation error IIRC.)
However, is it possible to handle both exceptions if the method throws only the most generic i.e >IOException?
catch(IOException ex){
if(ex instanceof FileNotFoundException){}
}
But this doesn't look clean, Throwing both exception looks good, even caller would come to know to that this method may throw these these exceptions, so they will handle it properly
Yes, it's possible to handle both if the method only throws IOException.
The best way to answer such a question is to write a test to demonstrate it and try it out. Let the JVM tell you the answer. It'll be faster than asking here.
yes. when certain specialized exceptions can be handled correct. It is, if you handle the exceptions as follow:
try {
} catch (FileNotFoundException f) {
//Try a different file
} catch (IOException ioe) {
//Fatal, Maybe bad blocks ... Bail out...
} catch (Exception e) {
//Something went wrong, see what it is...
}
Declaring, that the method may throw (more generic) IOException, and (more specific) FileNotFoundException is usually a good thing - it's an additional information for people using your code later. Note that you should explicitely state in the JavaDoc, under what circumstances is each of the exceptions thrown.
They will still be able to distinguish the exceptions, and handle them differently using catch constructs like this one:
try {
yourAwesomeMethod()
} catch (FileNotFoundException ex) {
// handle file-not-found error
} catch (IOException ex) {
// handle other IO errors
}
Related
What is the best practice to terminate the execution of an overridden method?
Here is the example code that explains the context:
#Override
protected String doInBackground(String... params) {
URL serverURL = null;
try {
serverURL = new URL((urlString));
} catch (MalformedURLException e) {
e.printStackTrace();
}
...
...
return response.toJSONString();
}
In the above code snippet, I am forced to catch MalformedURLException, so I used the try catch block. If that exception occurs, I would like to skip all the code below the catch block and propagate either the same exception or a different one that I would throw within the catch block until all the way to the Main method, hopping through the catch blocks and skipping the code in the middle in all the calling methods. How to do this?
The problems are:
1) I cannot add throws clause to the method signature because it is overridden and the base class doesn't allow it.
2) Since the method has to return a String, I have to specify the return statement after the catch block.(What do I return if an exception has occurred?)
3) Use System.exit in catch block - As some other posts on this forum point out, that may not be a good practice when you want your code to be reusable.
The best practice for such a case would be to wrap the MalformedURLException with a RuntimeException:
catch (MalformedURLException ex) {
throw new RuntimeException("Failed constructing URL", ex);
}
Ideally, you'd really like to edit the method's throws clause so it can accommodate any exceptions that are likely to stem from overrides; but since this is impossible in your case (as per your conditions), the above seems most reasonable to me.
A related best-practice would be to avoid logging the exception before wrapping it. From a design perspective, there's no need to do so — the caller already has access to the original Exception object (through the getCause() method of the thrown RuntimeException) so the caller should decide whether to log it or not.
I know that the code below does make sense:
try { ... }
catch (FileNotFoundException exc) { ... }
catch (IOException exc) { ... }
But does declaring those parent and child exceptions in the throws clause make sense?
Suppose I have the following code:
public void doSomething() throws FileNotFoundException, IOException { ... }
We all know that FileNotFoundException is a subclass of IOException. Now does it make sense in any way (readability, performance, et cetera) to declare it like that, opposing to just this:
public void doSomething() throws IOException { ... }
For the Java compiler, it doesn't matter whether a subclass is in the throws clause, because the superclass exception will cover it.
However, for documentation purposes it is important. The caller of your method may want to know that it can throw a subclass exception, e.g. FileNotFoundException, and handle it differently.
try {
doSomething();
}
catch (FileNotFoundException e) {
System.out.println("File not found!");
}
catch (IOException e) {
System.out.println("An I/O error has occurred: " + e.getMessage());
}
Sometimes it makes sense to catch both exceptions, as long the the sub-class exception is specified first (otherwise, I think it won't even compile). It allows you to handle specific exceptions you care about in a different way than more general exceptions.
For example, I have code that reads from a socket. It's a blocking read, an I set a timeout, since there might be nothing to read. That's why I catch SocketTimeoutException and do nothing about it. If, on the other hand, I get other IOExceptions (IOException being an indirect super-class of SocketTimeoutException), I am throwing an exception, since a real failure happened while trying to read from the socket.
catch (SocketTimeoutException ignEx) {
// -- ignore exception, as we are expecting timeout exceptions because
// -- there might be nothing to read
}
catch (IOException ioEx) {
throw new SomeException (...);
}
As for declaring both in the method signature, It is not necessary to declare both in the throws clause, but it would be useful to the users of your method if you document both exceptions in the JavaDoc comments, and describe the conditions in which each of them are thrown.
public void backendExecute(Map appParams, BackendTaskMetaData metaData) throws Throwable {
try {
PeriodicTaskData ptd = (PeriodicTaskData) appParams.get(PeriodicTaskData.PARAM_KEY);
String bizKey = ptd.getBusinessKey();
} catch (Exception e) {
LogServices.app.error("RPTPeriodicReportGenTask:"+ e.getMessage());
}
}
With regards to the method above, if object pointed to is null, would come across as NullPointerException, I want to know if this exception would be caught or thrown to the invoker method? thanks
Exception is a parent class of NullPointerException, so it will catch it and not throw it to the calling method.
As you are catching Exception class and NullPointerException is its subclass , exception will get catched not throwed.
Regard to above method, if object ptd is null, would come across nullpointexception,
Yes.
i want to know this exception would be catch or throw it to invoker method?
The exception would be caught by the handler. The handler will catch Exception and any exception that is descended from it. NullPointerException is a subclass of RuntimeException which is (in turn) a subclass of Exception. Therefore, it will be caught.
Now, if this may be just an illustrative example ... but it is a bad idea to:
declare a method as throws Throwable, or
catch Exception ... unless you are about to terminate the application.
Declaring a method as throwing Throwable makes it next to impossible for the caller to know what exceptions could be thrown. Instead, the compiler will insist that the caller catches ... or propagates Throwable.
Catching Exception has the problem that you will catch every subtype of Exception ... including various unchecked exceptions that 1) you are not expecting, and 2) are probably symptoms of bugs that you cannot safely recover from.
NullPointerException is a subclass of Exception and thus will be catched, however it is recommended that you don't try and catch runtime exceptions. It is better to avoid them.
For example a null pointer could be avoided by doing the following:
if(ptd != null) {
ptd.getBusinessKey();
} else {
//Notify the user in some way or do something else.
}
catch (Exception e)
means that this will catch any exception (i.e. any subclass of Exception) thrown inside the preceding try block - which, yes, includes NullPointerException. Note that this is generally considered a bad practice, as you almost always will want to handle different sorts of exceptions in different ways, hence the need for multiple catch statements.
For instance, consider a method that could potentially throw an IllegalAccessException at compile time or a NullPointerException at runtime - it's difficult to imagine a situation where you'd want to handle them the same way, so you'll typically want to do something like this:
try {
PeriodicTaskData ptd = (PeriodicTaskData) appParams.get(PeriodicTaskData.PARAM_KEY);
String bizKey = ptd.getBusinessKey();
} catch (NullPointerException e) {
//do something
} catch (IllegalAccessException e) { //for example...
//do something different
}
If I have unhandled exception in Java, Eclipse proposes two options to me: (1) add throws declaration and (2) surround with try/catch.
If I choose (2) it adds a code
try {
myfunction();
} catch (MyUnhandledException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
I want to change this to
try {
myfunction();
} catch (MyUnhandledException e) {
throw new RuntimeException(e);
}
Is this possible?
UPDATE
Why are so love to change the topic people???
If exception is catched and printed it is also no need to catch it anymore. I like my application to crash if I forget to handle an exception by mistake. So, I like to rethrow it by default.
Yes, you can change the default code added by Eclipse.
In Preferences, navigate to Java>Code Style>Code Templates.
Under Code, select Catch block body.
Press the Edit button to change the code. When finished, press the
OK button.
Consider adding a TODO comment in the default catch block. For example, the default includes:
// ${todo} Auto-generated catch block
Personally, I use a generic idiom irrespective of the actual checked exception type, you might make Eclipse use that as a template instead:
try {
...
}
catch (RuntimeException e) { throw e; }
catch (Exception e) { throw new RuntimeException(e); }
The point is to wrap the whole code block instead of individually each line that may throw an exception. The block may throw any number of checked and unchecked exceptions, and this will allow the unchecked exceptions to pass through unharmed, and the checked exceptions will be wrapped.
If you are re-throwing your exception from the catch clause, then you would have to handle in the method that invoked your current method. But if you wrap your exception in RuntimeException, you won't need to handle it. But why would you do that?
I mean why not just: -
try {
myfunction();
} catch (MyUnhandledException e) {
throw e;
}
Because, in your code, basically you are wrapping a might be checked exception in an unchecked one. If I assume your MyUnhandledException as checked exception.
And also note that, if you are following this approach, you would still need to declare it to be thrown in your throws clause.
If you just want to do the way you are doing, then also it will work fine. You can change the Eclipse setting as per #Andy's answer.
But, it would be better to look at your design. Why is the method overrided throwing an exception not declared in your overriden method. Probably there is something wrong, that should be corrected.
You're probably aware of this... but if you want to get rid of all pesky clutter and irritations from checked exceptions, why not just add throws Exception to every single method?
In the case of an overridden interface method this sort of pattern could then be used:
#Override
public void close() throws IOException {
try {
_close();
} catch (Exception e) {
// TODO Auto-generated catch block
throw new RuntimeException(e);
}
}
private void _close() throws Exception {
// ... closing ops
}
I have basic doubt in Java Exceptions
i.e., All checked exceptions extends from Exception class and Unchecked Exceptions extend from RuntimeException. But Runtime Exception also extends from Exception.
But why to propagate try... catch block with checked Exceptions but not in Unchecked Exceptions?
In general, you should add different catch blocks for each specific type of exception you intend to handle. If you're trying to handle (by rethrowing) checked exceptions, then you should know which type of exceptions to rethrow -- just add a catch block to rethrow each of those exception types.
I think you are asking, "How can I catch Exception but not RuntimeException ?
You probably should not be trying to do that. You should catch specific types of exceptions when possible. If you need to handle all errors, then you should catch Exception and that catches everything.*
You would rarely want to do catch (NullPointerException) because if you ever know that you can have a null then you should check for it. If your code is causing NullPointerException or ArrayOutOfBoundsException then you should fix the code so that it no longer throws those.
This code should show you how to do what you asked about:
public static void throwSomething(Exception throwMe)
{
try {
throw throwMe;
}
catch(Exception ex) {
// Check if the object is a RuntimeException
if(ex instanceof RuntimeException) {
// Throw the same object again.
// Cast to RuntimeException so the compiler will not
// require "throws Exception" on this method.
throw (RuntimeException) ex;
}
System.out.println("Caught an instance of a " +
ex.getClass().toString());
}
}
*Actually, catch(Throwable) will catch everything including Errors.
The easiest way is this:
try {
//do stuff
} catch(RuntimeException e) {
throw e;
} catch(SpecificCheckedException e) {
//handle
} catch(Exception e) {
//handle
}