Just found a bug in this code :
for(String link : tempList1){
if(!tempList2.contains(link));{
listToPopulate.add(link);
}
}
The ';' at the end of if(!tempList2.contains(link)) causes the condition to evaluate to true, even though it should be false. Why is this occurring ?
Fix is to just remove the ';'
The compiler sees an if condition followed by a stand-alone block. With standard indenting, it would look like this:
for(String link : tempList1){
if(!tempList2.contains(link))
; // ; is a no-op statement.
{
listToPopulate.add(link);
}
}
http://en.wikipedia.org/wiki/NOP#NOP_code
The simplest possible statement in C that behaves like a NOP is the so called null statement, which is just a semi-colon in a context requiring a statement.
Java inherited this syntax from C.
The ; in line 2 ends the block following the if. The next { opens a new block that has no condition around it.
if(expr);
{
dosomething();
}
is the same as
if(expr)
{
}
{
dosomething();
}
e.g. the block containing dosomething is not part of the if statement since the ; terminates the if statement.
The if statement is not evaluating to true, it's just not relevant.
As others said,
if([condition]);
somecode;
is similar to
if([condition])
{}
somecode
If you are using Eclipse, you can enable the "empty statement" warning. This will let you see easily when such an empty statement is written, as this is generally unintended and can be annoying to debug. It is in Eclipse preferences (Java > Compiler > Errors/Warnings).
Because the ; is causing the end of the if condition, causing the if statement itself to have no effect.
The above is equivalent to:
for(String link : tempList1){
if(!tempList2.contains(link)) {
// do nothing
}
// the below is just an empty block, it will be executed always.
{
listToPopulate.add(link);
}
}
The evaluation of the condition does not change. What does change, however, is that the following line is no longer inside the loop and is executed unconditionally:
listToPopulate.add(link);
In other words, the code becomes equivalent to:
for(String link : tempList1){
if(!tempList2.contains(link)) {
}
listToPopulate.add(link);
}
Semicolon designates the end of the statement and {} indicate a new block of code. So the condition is evaluated and ignored as there is a semicolon. and listToPopulate.add(link); is always executed as it is not tied to earlier if statement.
Related
I know questions like this are everywhere, but I read a lot of things about this, and I still can't understand what the "throws" command do. I will be more specific now:
So, one of the examples I saw was this one, with the following code:
public class CatchThrow {
private static void throwsMethod() throws NumberFormatException {
String intNumber = "5A";
Integer.parseInt(intNumber);
}
private static void catchMethod() {
try {
throwsMethod();
} catch (NumberFormatException e) {
System.out.println("Convertion Error");
}
}
public static void main(String[] args) {
// TODO Auto-generated method stub
catchMethod();
}
}
Now, if I remove the "throws NumberFormatException" from the "throwsMethod" method, the program will run the same, and will give the same results. Actually, every example with the throws command that I saw did the same, so I can't really understand why use it.
I'm using the Eclipse IDE, version 4.7.2.
Normally your function exits at the end of the function or the return statement.
However, a function can also exit when it reaches a throw statement. If the exception subclasses Exception, the caller of the function must surround the function call with a try { } catch { } block. If the exception subclasses RuntimeException you may optionally surround the function call in a try catch block.
If you look at the JavaDoc for NumberFormatException: https://docs.oracle.com/javase/7/docs/api/java/lang/NumberFormatException.html will see it subclasses RuntimeException. This means your try-catch block is optional. The difference between the two program is this: With the try-catch block you will get Convertion Error printed to the console, without it, you will see the full stack trace. This is often called "swallowing the exception".
So basically, if an exception occurs and you don't want to handle that exception there, in that case you use the 'throw' keyword to simply just throw the exception if occurs.
Example: Here, in throwsMethod(), you are not taking care of the Exception Handling i.e. not using the try(), catch() blocks, you are just throwing it if there occurs any Exception. And you will land in catch() block if exception occurs in your throwsMethod().
To get better idea, you should read checked & Unckecked exceptions in Java. For Checked exceptions (happen at compile-time), we use 'throw' keyword and for Unchecked (Run-time), we use try() catch().
Example: NumberFormatException is an Unchecked exception, IOException is a Checked exception.
Read this for reference: https://www.geeksforgeeks.org/checked-vs-unchecked-exceptions-in-java/
Here is the code:
public static String readFile(InputStream is) {
try (Scanner scanner = new Scanner(is); Scanner delimitedScanner = scanner.useDelimiter("\\A");) {
return scanner.hasNext() ? scanner.next() : "";
}
}
And findbugs plugin says:
Redundant nullcheck of value known to be non-null This method contains
a redundant check of a known non-null value against the constant nul
And points on this:
return scanner.hasNext() ? scanner.next() : "";
} //this line contains bug!!!
}
Look at the pic:
And eclipse shows the same warning:
The try-with-resources constructs confuses code analyzers and coverage tools that look directly at the byte code. At the end of the try-with-resources block a lot of extra byte code is generated that will have the ending brace as its line number.
Apparently FindBugs seems to think there is a problem there. However, this is almost certainly not the case.
The same thing happens with coverage tools, even though the block is fully covered, they claim that not all branches were covered. This is because the try-with-resources block adds handling for exceptional cases or resources being null which you can't really get covered properly with for example Unit tests.
The problem lies with the JDK which rewrites try-with-resources to the form:
Scanner scanner = null
try {
scanner = new Scanner(is);
} finally {
if (null != scanner) {try {scanner.close();} catch (Exception e) {...}}
}
Seems like this should already be fixed, so please check your findbugs plugin version.
(https://sourceforge.net/p/findbugs/bugs/1169/)
In my eclipse plugin I use a ScheduledExecutorService for a repeating task. However this seems to lead to some unreachable code within the scheduled task because I can set a breakpoint in eclipse up to a certain line and it will be reached in the debugger but when I set it one line further it is not reached... Just nothing happens then, no exception just nothing.
When I try to overstep this respective line I land somewhere in the sources of the ScheduledThreadPoolExecutor and my stack shows this:
ScheduledThreadPoolExecutor$ScheduledFutureTask<V>(FutureTask<V>).run() line: not available [local variables unavailable]
Whats going on here?
Okay the problem was that there was actually an exception being thrown but it seems like the ScheduledExecutorService swallows it without telling anything about it...
I foud this out by surrounding my code in the run-method with a generic try-catch-block like this:
#Override
public void run() {
try {
// Code
} catch (Exception e) {
e.printStackTrace();
}
}
How much better is:
if (condition) {
try {
//something
} catch(SomeEx ex) {}
}
instead of this:
try {
if (condition) {
//something
}
} catch(SomeEx ex) {}
What actually JVM do when I enter try block ?
EDIT:
I don't want to know that in second example always go in to try... Please answer the question.
Execution wise at run time, as long as there is no exception, try does not cost you anything. It only costs run time as soon as an exception occurs. And in that situation it is much slower that an if evaluation.
In the JVM spec, you see that there is no extra byte code generated on the execution path:
http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-3.html#jvms-3.12
try {if (condition) {...}} catch(SomeEx ex) {}
Here you handled the exception if it is arised condition of if also if arised inside if-block.
if (condition) {try {...} catch(SomeEx ex) {}}
Here you handle exception if is arised only inside the if-block. If something goes wrong in if condition then it will not be handled.
So it is depends upon the actual senario.
From the perfomance point of view it should be the same. Throwing of the exception is a costly operation (for starters, the stacktrace must be created and populated). The mere existence of the try block has no (or negligible) performance penalty.
See Should java try blocks be scoped as tightly as possible.
What actually JVM do when I enter try block ?
From JLS 14.20.1. Execution of try-catch:
A try statement without a finally block is executed by first executing the try block. Then there is a choice:
If execution of the try block completes normally, then no further action is taken and the try statement completes normally.
If execution of the try block completes abruptly because of a throw of a value V, then there is a choice:
If the run-time type of V is assignment compatible with (ยง5.2) a catchable exception class of any catch clause of the try statement, then the first (leftmost) such catch clause is selected. The value V is assigned to the parameter of the selected catch clause, and the Block of that catch clause is executed, and then there is a choice:
If that block completes normally, then the try statement completes normally.
If that block completes abruptly for any reason, then the try statement completes abruptly for the same reason.
If the run-time type of V is not assignment compatible with a catchable exception class of any catch clause of the try statement, then the try statement completes abruptly because of a throw of the value V.
If execution of the try block completes abruptly for any other reason, then the try statement completes abruptly for the same reason.
EDIT:
For a complete Exception description see the JVM 2.10 link in The New Idiot's answer.
If you see oracle docs
>try {
code
}
catch and finally blocks . . .
The segment in the example labeled code contains one or more legal lines of code that could throw an exception.
So,If you feel doubt on your If condition that it will throw an exception put it inside.Otherwise put outside.
if (condition) {
try {
//something
} catch(SomeEx ex) {}
}
is better to use since it executes the try block if the condition is ok.JVM compiles the try block and validated the catch block or a finally block. I think advantage is not in the compile time but in the run time. Compile time I think no advantage at all
Exceptions should be exceptional case , not every time the code runs. So better to check for the condition before trying !
if (condition) {
try {
//something
} catch(SomeEx ex) {}
}
Make sure , if (condition) itself doesn't throws an Exception.
It depends on your usage and functionality . For example this would be better :
if (someObject!=null) {
try {
someObject.getSomething(); // getSomething() potentially throws some Exception
} catch(SomeEx ex) {}
}
What actually JVM do when I enter try block ?
Read JVM spec 2.10.
I was surprised recently to find that it's possible to have a return statement in a finally block in Java.
It seems like lots of people think it's a bad thing to do as described in 'Don't return in a finally clause'. Scratching a little deeper, I also found 'Java's return doesn't always' which shows some pretty horrible examples of other types of flow control in finally blocks.
So, my question is, can anyone give me an example where a return statement (or other flow control) in a finally block produces better / more readable code?
I had a REALLY hard time to track down a bug years ago that was caused by this. The code was something like:
Object problemMethod() {
Object rtn = null;
try {
rtn = somethingThatThrewAnException();
}
finally {
doSomeCleanup();
return rtn;
}
}
What happened is that the exception was thrown down in some other code. It was being caught and logged and rethrown within the somethingThatThrewAnException() method. But the exception wasn't being propagated up past problemMethod(). After a LONG time of looking at this we finally tracked it down to the return method. The return method in the finally block was basically stopping the exception that happened in the try block from propagating up even though it wasn't caught.
Like others have said, while it is legal to return from a finally block according to the Java spec, it is a BAD thing and shouldn't be done.
The examples you provided are reason enough to not use flow-control from finally.
Even if there's a contrived example where it's "better," consider the developer who has to maintain your code later and who might not be aware of the subtleties. That poor developer might even be you....
javac will warn of return in finally if you use the -Xlint:finally. Originally javac emitted no warnings - if something is wrong with the code, it should fail to compile. Unfortunately backwards compatibility means that unanticipated ingenious foolishness cannot be prohibited.
Exceptions can be thrown from finally blocks, but in that case the exhibited behaviour is almost certainly what you want.
Adding control structures and returns to finally{} blocks are just another example of "just because you can" abuses which are scattered throughout virtually all development languages. Jason was right in suggesting it could easily become a maintenance nightmare - the arguments against early returns from functions apply more-so to this case of "late returns".
Finally blocks exist for one purpose, to allow you to completely tidy up after yourself, no matter what happened in all the preceeding code. Principally this is closing / releasing file pointers, database connections etc., though I could see it being stretched to say adding in bespoke auditing.
Anything that affects the return of the function should lie in the try{} block. Even if you had a method whereby you checked an external state, did a time consuming operation, then checked that state again in case it became invalid, you would still want the second check inside the try{} - if it sat inside finally{} and the long operation failed, you would then be checking that state a second time needlessly.
A simple Groovy Test:
public class Instance {
List<String> runningThreads = new ArrayList<String>()
void test(boolean returnInFinally) {
println "\ntest(returnInFinally: $returnInFinally)"
println "--------------------------------------------------------------------------"
println "before execute"
String result = execute(returnInFinally, false)
println "after execute -> result: " + result
println "--------------------------------------------------------------------------"
println "before execute"
try {
result = execute(returnInFinally, true)
println "after execute -> result: " + result
} catch (Exception ex) {
println "execute threw exception: " + ex.getMessage()
}
println "--------------------------------------------------------------------------\n"
}
String execute(boolean returnInFinally, boolean throwError) {
String thread = Thread.currentThread().getName()
println "...execute(returnInFinally: $returnInFinally, throwError: $throwError) - thread: $thread"
runningThreads.add(thread)
try {
if (throwError) {
println "...error in execute, throw exception"
throw new Exception("as you liked :-)")
}
println "...return 'OK' from execute"
return "OK"
} finally {
println "...pass finally block"
if (returnInFinally) return "return value from FINALLY ^^"
// runningThreads.remove(thread)
}
}
}
Instance instance = new Instance()
instance.test(false)
instance.test(true)
Output:
test(returnInFinally: false)
-----------------------------------------------------------------------------
before execute
...execute(returnInFinally: false, throwError: false) - thread: Thread-116
...return 'OK' from execute
...pass finally block
after execute -> result: OK
-----------------------------------------------------------------------------
before execute
...execute(returnInFinally: false, throwError: true) - thread: Thread-116
...error in execute, throw exception
...pass finally block
execute threw exception: as you liked :-)
-----------------------------------------------------------------------------
test(returnInFinally: true)
-----------------------------------------------------------------------------
before execute
...execute(returnInFinally: true, throwError: false) - thread: Thread-116
...return 'OK' from execute
...pass finally block
after execute -> result: return value from FINALLY ^^
-----------------------------------------------------------------------------
before execute
...execute(returnInFinally: true, throwError: true) - thread: Thread-116
...error in execute, throw exception
...pass finally block
after execute -> result: return value from FINALLY ^^
-----------------------------------------------------------------------------
Question:
One interesting point for me was to see how Groovy deals with implicit returns. In Groovy it is possible to "return" from a method simply leaving a value at the end (without return). What do you think happens, if you uncomment the runningThreads.remove(..) line in the finally statement - will this overwrite the regular return value ("OK") and cover the exception?!
Returning from inside a finally block will cause exceptions to be lost.
A return statement inside a finally block will cause any exception that might be thrown in the try or catch block to be discarded.
According to the Java Language Specification:
If execution of the try block completes abruptly for any other reason
R, then the finally block is executed, and then there is a choice:
If the finally block completes normally, then the try statement
completes abruptly for reason R.
If the finally block completes abruptly for reason S, then the try
statement completes abruptly for reason S (and reason R is
discarded).
Note: As per JLS 14.17 - a return statement always completes abruptly.