I'm doing a review for our codebase, and there are many statements like this:
try
{
doSomething()
} catch (Exception e)
{
}
but I would like a way to know which exception is thrown by doSomething() (there's no throw statement in the implementation of doSomething) so i can catch that exception instead of just catching Exception in general, even with findBugs it gives a warning REC_CATCH_EXCEPTION.
I should mention that logging the exception or printing it to console will not help me because it takes time in this case to reproduce the error that causes the exception here.
Thanks
If there's no throws statement in doSomething (e.g. doSomething() throws IOException), any exceptions that will occur will be an instance of RuntimeException. If you want to know the exact class of an exception thrown by doSomething, you can always try
try {
doSomething();
} catch (RuntimeException e){
System.out.println(e.getClass().getName());
}
Knowing which runtime exceptions can be thrown without actually running the program is difficult. Even if none of the code that doSomething() calls has an explicit throw, core java operations can always throw NullPointerException, ArrayIndexOutOfBoundsException, etc with the wrong input. Here are some ideas:
Dig through manually. At least you will know some of the exceptions.
Use reflection to find any throw statements accessible from doSomething.
Run your test cases and log the exceptions thrown like above. Good tests will reveal the important errors that callers of doSomething should be ready for.
Go to the people who put the catch there in the first place
In any case it's usually a good idea to catch exceptions that are as specific as possible, since you don't know exactly what went wrong when you try to deal with all cases in one clause.
You can 1) dig through all the code in doSomething() and everything it calls to see the exception handling and what RuntimeExceptions can be thrown, or 2) take of the catch (Exception e) and wait for it to fail. This is the problem that checked exceptions attempted to overcome by making a strongly-typed declaration in method signatures about what exceptions must be handled as a result of calling the method.
If there is no throws clause, then the method does not throw any checked execption. The javadoc of that method might give information about any unchecked exceptions the method can throw, but it does not have to.
Why do you want to catch any exceptions in the first place?
Do you want to catch just compile-time exceptions or run-time exceptions as well? If you only want to catch the compile-time ones, just remove your current catch block - you'll immediately get error messages stating that certain exceptions aren't being caught. After you add one exception, you'll see error messages for others - you'll be able to finish catching all possible exceptions thrown by your code block.
Related
A simple question and I can't find the answer for it.
Is it required to every exception in Java to use a try-catch? Or is it only for the FileNotFoundException?
A lot of exceptions (IndexOutOfBoundException, ArithmeticException, IlligalArgumentException, NullPointerException) are saying that they didn't need an Exception, but FileNotFoundException does)... and I can't find the answer which do and which doesn't need try-catch.
It's not absolutely required to have a try/catch block for your exceptions. Instead, you can throw them to someone who is able to handle the exception properly.
There are 2 kinds of exceptions: Checked and Unchecked. A Checked exception can be considered one that is found by the compiler, and the compiler knows that it has a chance to occur, so you need to catch or throw it. For example, opening a file. It has a chance to fail, and the compiler knows this, so you're forced to catch or throw the possible IOException.
An Unchecked exception can be considered one that has a chance of occurring, but based on your code, the compiler doesn't know. In other words, it's a programming error. For example, if you're taking user input and expect a number, and the user enters something you didn't expect, such as a string, your program would throw a NumberFormatException. You can predict these scenarios and put try/catch to try and avoid them before they occur. Very rarely seen is a person adding a throws NullPointerException or throws NumberFormatException (or throwing any other Unchecked exception, for that matter). It's allowed, but explicitly creating that exception is weird and most people would say that it's bad coding style.
Note that all Checked suggestions must be caught or thrown to something that can handle it; if you don't do it, your program won't compile. If you throw it to something that can't handle it, then your program will likely crash if it occurs.
Also note that an unchecked Exception (eg: one that occurs during runtime, usually via bad user input or whatnot) will also usually crash your program. Thus, it's usually a good idea to use try/catch when something can potentially go wrong, but you don't have to.
Also interesting to note is that while Checked exceptions are subclasses of Exception and Unchecked exceptions are subclasses of RuntimeException, RuntimeException itself is a subclass of Exception. That means that if you really wanted to, a single try {} catch (Exception e) {} will catch every single exception your program could possibly throw. Granted, this is considered a horrible way to deal with exceptions, and you should catch each one separately so that you can handle them separately. Please try not to use it.
No, not every exception requires a try-catch. Every checked exception requires a try catch. For example, a NullPointerException is an unchecked exception, so it does not require a try-catch, whereas a FileNotFoundException is checked, so it does require one. You can also add "throws" to the method signature and thus avoid needing a try-catch.
Read:
https://docs.oracle.com/javase/tutorial/essential/exceptions/
Basically checked Exceptions need to be handled or thrown
Unchecked Exceptions and Errors may be handled or thrown (although handling Error is in general considered bad practise).
Checked exception is everything that inherits from java.lang.Exception
Unchecked exception is everything that inherits from java.lang.RuntimeException
Error is everything that inherits from java.lang.Error
Only Checked exception explicit need to catch it, for other all kind of exception you can use "throws" to the method signature.
Yes, but if you don't want to handle it in your method you can pass the exception to the caller of the method with the throws keyword. Example:
void execption() throws Exception {
throw new Exception();
}
void caller() {
try {
execption();
} catch (Exception e) {
e.printStackTrace();
}
}
Edit: I'm a bit rusty on my java, like josh said you can have unchecked exceptions that don't need a try/catch like NullPointerException, but you can add one if you think an unchecked exception may be thrown. Example:
Object obj = null;
obj.hashCode();// if you think a NPE will be thrown you can use a try/catch here
When a method that you call explicitly throws an exception then you have to use try....catch loop. But in case of the list you have given are all runtime exceptions. They get thrown when sometimes a program has inputs that were not expected or the program was put to some use that it was not intended for. These would not require a try....catch loop.
Example bellow a program ,where in try block defectedCode() method is called ,So why only output shown only C with "Exception in thread "main" java.lang.Error".
public class ExceptionTest {
public static void defectedCode(){
throw new Error();
}
public static void main(String args[]){
try{
defectedCode();
System.out.println("A");
}catch(Exception e){
System.out.println("B");
}finally{
System.out.println("C");
}
System.out.print("D");
}
}
Exception in thread "main" java.lang.Error
C
at ExceptionTest.defectedCode(ExceptionTest.java:15)
at ExceptionTest.main(ExceptionTest.java:21)
Java Result: 1
The main reason for this is that you throw an Error but you catch an Exception.
If you look at the Throwable hierarchy the point is clear. You can't catch an Error with an Exception. Hence the catch block isn't entered and finally will be called.
Try this:
try{
defectedCode();
System.out.println("A");
}catch(Throwable e){
System.out.println("B");
}finally{
System.out.println("C");
}
You're not supposed to catch errors
An Error "indicates serious problems that a reasonable application should not try to catch."
while
An Exception "indicates conditions that a reasonable application might want to catch."
Talking about your code, you're throwing an error and catching an exception, it must be evident by now that they are 2 discrete entities
Error along with RuntimeException & their subclasses are unchecked exceptions. All other Exception classes are checked exceptions.
Checked exceptions are generally those from which a program can recover & it might be a good idea to recover from such exceptions programmatically. Examples include FileNotFoundException, ParseException, etc. A programmer is expected to check for these exceptions by using the try-catch block or throw it back to the caller
On the other hand we have unchecked exceptions. These are those exceptions that might not happen if everything is in order, but they do occur. Examples include ArrayIndexOutOfBoundException, ClassCastException, etc. Many applications will use try-catch or throws clause for RuntimeExceptions & their subclasses but from the language perspective it is not required to do so. Do note that recovery from a RuntimeException is generally possible but the guys who designed the class/exception deemed it unnecessary for the end programmer to check for such exceptions.
Errors are also unchecked exception & the programmer is not required to do anything with these. In fact it is a bad idea to use a try-catch clause for Errors. Most often, recovery from an Error is not possible & the program should be allowed to terminate. Examples include OutOfMemoryError, StackOverflowError, etc.
Do note that although Errors are unchecked exceptions, we shouldn't try to deal with them, but it is ok to deal with RuntimeExceptions(also unchecked exceptions) in code. Checked exceptions should be handled by the code.
Because Error is not Exception, so the catch block is not monitoring it
use throw new Exception()
An Error is not an Exception.
The base class for throwable objects is Throwable.
Errors and exceptions are two different types of throwables. However, errors are usually not supposed to be caught, which is why people use catch(Exception e) to catch basically all exceptions that they should catch.
Obviously, since Error is not a subclass of Exception, it's not affected by catch(Exception e), so it's not caught. finally is always executed, regardless of whether the throwable has been caught or not.
Though ethically you should not catch an error, you can still catch that as a Throwable Object.
So my custom exception is PatternFormatException, and I've appended throws PatternFormatException, to the end of my method, but I'm wondering how I can actually get the method to physically throw it? Do I use if statements? i.e.
if //[doesn't_parse] throw PatternFormatException
This seems cumbersome for many different lines of code? Can I catch a more universal in built exception i.e. NumberFormatException, and then in the handling of this, throw my own exception?
You throw an exception using the throw keyword:
throw new PatternFormatException(...);
Generally you want to catch exceptions as early as they occur and handle them properly. If you want your parser (or whatever program you are writing) to generate meaningful errors, it's usually a good idea to wrap any caught exception and re-throw it, embedded in a more meaningful exception, giving the user a better idea of how things went wrong.
Something like this:
try {
doSomething(); // throws SomeException
doSomethingElse(); // throws SomeOtherException
}
catch (Exception e) {
throw new PatternFormatException(..., e);
}
generally is fine, if you know exactly what exceptions might happen and if all of them are properly encapsulated by PatternFormatException. However, the key idea of Exceptions in Java is that you are always aware of all the possible Exceptions that can happen. That is why Java forces you to add all possibly thrown Exceptions (except for RuntimeException) to the method declaration.
A safer design would be:
try {
doSomething(); // throws SomeException
doSomethingElse(); // throws SomeOtherException
}
catch (SomeException e) {
throw new PatternFormatException(..., e);
}
catch (SomeOtherException e2) {
throw new PatternFormatException(..., e2);
}
catch (Exception e3) {
throw new UnexpectedPatternFormatException(..., e3);
}
Note that the first two catches call different constructors, and thus can handle different Exceptions differently. The last catch wraps an unexpected exception because your program encountered an exception (probably a RuntimeException) that you did not plan for. If users then complain about UnexpectedPatternFormatException, you can just go back to your code and fix the code so that the underlying Exception either does not get thrown anymore or gets wrapped in a more meaningful way. You can also just use a single UnexpectedMySomethingException class as the fall-back for all try/catch blocks that you have, to keep things a bit simpler.
One last word should be said about issues caused by Exceptions: Even though, Java uses Exceptions for all kinds of situations, even those that are largely not in the control of the Java programmer (e.g. when accessing files or even trying to parse strings as numbers), always be aware that throwing and catching Exceptions is actually quite expensive, which is why many people tend to avoid that. Only really use Exceptions, if performance is not of an issue (when the Exception is a rare event).
Also, Exceptions can threaten the integrity of your program's state if you throw an Exception and catch it too late, so that lines that should have been executed did not get executed (e.g. code for cleaning up resources or other code that is needed to keep the program state "correct"), and, as a result, the only safe thing to do is to shut down the program.
If I understand your question correctly you could just do this:
If(somethingBad){
throw new PatternFormatException();
}
As stated in a response below. If your going to check this exception over and over again you might want some Static Method/Class Method (use your programming brain). For example you could do something like:
void checkForException(String pattern, String check){
If(!check.equals(pattern)){
throw new PatternFormatException();
}
}
Now all you have to do is:
try{
checkForException("abc","123");
}catch(PatternFormatException pfe){
System.out.println(pfe); //Whatever you want to happen if the exception is thrown
}
Remember though, ONLY use exceptions for exceptional situations...
Have a read over this for more information on exceptions. I find that I next to never use exceptions.
I have a method throws an Exception
public int myMethod throws Exception
I have another function calls myMethod function and hava try-catch block.
I throws a runtime exception to enforce the program to be terminated.
Is this a proper way to terminate the program? If I do this way, it prints the stack trace twice and the stack trace from RuntimeException is useless.
What is the suggested way to terminate program in catch clause with printing the full stack trace.
public int callMyMethod(){
try{
myMethod();
}
catch(Exception ex){
ex.printStackTrace(System.out);
throw new RuntimeException();
}
}
The answer is "it depends".
If this code is part of the application itself then calling System.exit(int) is possibly the best option. (But if the application is "failing", then you should call exit with a non-zero return code. Zero conventionally means "succeeded".)
However, if there is a significant possibility that this code is going to be embedded / reused in a larger Java application, calling System.exit(...) is problematic. For instance a library that calls System.exit(...) when something bad happens is going to cause havoc for an application that uses it.
For something like that, you might throw a custom runtime exception which you catch and handle specifically in your main method. (If I was doing that, I'd pass the Exception as a constructor parameter to the custom exception ... and make it the cause exception. And I wouldn't print it / log it at that point.)
(Calling System.exit(...) also causes problems when you are unit testing ... 'cos the call will most likely pull the plug on the JVM running the test suite!)
The other point is that catch (Exception ...) is almost always a BAD IDEA. The point is that this catches just about everything (including all sorts of things that you never dreamed could happen!) and buries them. It is far better to catch the specific exceptions you are expecting (e.g. checked exceptions) and can deal with ... and just let the rest propagate in the normal way.
If you are stuck with catch (Exception ...) because you are using something that is declared as throwing Exception, the best way to deal with it is to change the throws Exception. And the sooner the better. Change the throws Exception to declare a list of (more) specific exceptions that you expect to be thrown by the method.
public int callMyMethod(){
try{
myMethod();
}
catch(Exception ex){
ex.printStackTrace(System.out);
System.exit(0); // terminates with exit code 0, no extra stack trace.
}
}
Exception handling is one of the most important aspects in programming.
The answer for your question depends on what type of application you are working on.
system.exit(0) will just terminate your program and this can create a lot of havoc .
Also make sure that you never catch Exception , if you are doing that then you are catching all the types of exceptions which you may not intend to handle also.
Always catch Specific exception such that it gives you opportunity to handle it in a manner which you need.
I want to know whether an error can be handled or not in Java in the similar way to exceptions. I have seen errors that can't be handled such as AssertionError and I've also tried throwing an error inside a program and tried handling using catch, It worked and also the next part of code did execute(This is contradictory to the part where the program supposed to be exited whenever an error is encountered). Is it like few errors can be handled and few others cannot be. I'm confused with this, can anyone clear this doubt of mine and state the difference between errors and exceptions?
package package1;
public class Class1
{
public static void main(String[] args)
{
Class1 cl1=new Class1();
int x=2;
String s = null;
//assert(x<0):"x is not less than zero";
try
{
cl1.workonExceptions();
}
catch (Error e)
{
e.printStackTrace();
}
System.out.println("Not Terminated yet");
}
public void workonExceptions() throws Error
{
try
{
throw new Exception("Exception");
}
catch (Exception e)
{
throw new Error("Exception Again"); }
}
}
Some background on Error: It's not intended to be catchable; it only comes up when something goes really wrong. An exception is meant to be caught and handled, since it's something that may come up on occasion, but shouldn't interrupt or interfere severely with the running of your program, such as dividing by zero.
As for it working inside of a try...catch statement, the reason is that this is a property of the Throwable class.
Only objects that are instances of this class (or one of its subclasses) are thrown by the Java Virtual Machine or can be thrown by the Java throw statement. Similarly, only this class or one of its subclasses can be the argument type in a catch clause.
Exceptions, if thrown from a method, are required by the compiler to be caught by callers of that method.
Errors, even if thrown from a method, are not required by the compiler to be caught by callers of the method.
Both Exceptions and Errors CAN be caught by callers, and behave the same way when they are. If you have code that illustrates "continues to execute", I'd be interested in seeing it. If you throw either of these (both derived from Throwable), execution of the method from which they are thrown ceases at that point (absent finally clauses, an (ahem) exception to the rule I'd rather not try to cover in this post).
All errors in Java are catchable, including AssertionError, although it is not recommended to catch them, and it is not guaranteed that the JVM is in consistent enough state to continue execution after an Error. So what you see is completely normal.
Differently from C#, even ThreadDeath is handled pretty much the same as any other Throwable (that is, it can be caught and consumed).
The main difference between errors and exceptions is that methods can throw any errors regardless of their exception specifiers.