Develop Reference

Is it possible to make a catch block that waits until the whole try block is executed?

What I'm doing
I'm trying to make a cleaner version of nested try catch blocks and I'm solving a very basic exception problem while doing so. I'm making a calculator that will do great things. Before then however, it must take in user inputs as strings and convert them to either floats or integers. I'm doing this by simply calling the in built parseInt and parseFloat functions of java. Right now I'm using a nested try catch block to do this:
String stringToParse = "1.0"
try{Integer.parseInt(stringToParse);}
catch(NumberFormatException n){
try{Float.parseFloat(stringToParse);}
catch(NumberFormatException n){
System.out.println(n)
}
}
Why is that a problem?
This is messy to me and I'd rather have a try block that collects the errors but doesn't immediately go to the catch block, rather it executes the entire try and catches any errors after the try has been executed. I've made a runnable example of this myself that shows what I desire:
String num = "1.0";
int i = 0;
ArrayList<Object> listofResults = new ArrayList<>();
ArrayList<Integer> listOfErrorIndices = new ArrayList<>();
try {
listofResults.add(Integer.parseInt(num));
i++;
listofResults.add(Float.parseFloat(num));
i++;
listofResults.add(Integer.parseInt(num));
} catch (NumberFormatException n) {
listOfErrorIndices.add(i);
}
for (Integer element:listOfErrorIndices) {
System.out.println(element);
//this currently prints out 0 and I want it to print out both 0 and
//2 so that it catches both errors.
}
My idea of how to solve the problem/What I've tried otherwise
My plan is to gather a list of all the NumberFormatException indices (i) thrown in the try. Each time I try to parse the string, an element is added to the resultsList. My goal is to then use this theoretical try catch block to obtain the indices of all the exceptions and then remove them from the resultsList if they threw an error. TLDR; Right now the above code prints out 0 and I want it to print out 0 and 2. Basically, Instead of having nested try catch blocks I use list comprehension and Exception handling indicies with i to remove the error results and only keep the good ones. I don't know if this is possible hence this question. I've looked at the "better ways to implement nested try catch blocks" question however it wasn't useful to me because It provided a solution in delphi and I didn't understand exactly how it worked or if it even worked the way I want mine to work. I at first thought the finally block might be what I needed but that only runs after the catch is executed or if there is no exception, after the try. I need something that postpones the catch block untill the try is complete and I can't think of/find anything that does that.
What are you, crazy?
right now you may be asking, what the hell is the point of this? Well imagine if you had the above problem but instead of two ways to parse the string you had 10 or 100. Pretty quickly, exception handling that with nested try catch blocks would be nigh impossible. I've seen solutions where the catch block calls a custom exception method that then at least takes care of the bad formatting. It looked like this:
try{
//bad code
}
catch{
trysomethingelse();
}
trysomethingelse(){
//equally bad code
catch{
//ya done screwed up son
}
}
However I'm not satisfied because it means that you need a million different method names just to potentially handle one error. Imagine the error would always be the same you just need to try 100 different string parsing methods. Its always going to be a numberformatException if you're trying to convert a string to a number so why have a million catch blocks just for the same error? I want to try to do this with one theoretical catch block that specifies one error that happens many times over in the try block.

You build a list/array of parsers, then iterate that list, catching exception for each.
With Java 8 method references, this is real easy. First, define a Parser functional interface that allows exceptions to be thrown:
#FunctionalInterface
public interface Parser {
Object parse(String text) throws Exception;
}
Next, build your array of parsers to try:
Parser[] parsers = {
Integer::valueOf,
Double::valueOf,
BigInteger::new,
BigDecimal::new
};
Finally, try them one at a time:
String text = "45.8";
Object[] results = new Object[parsers.length];
for (int i = 0; i < parsers.length; i++) {
try {
results[i] = parsers[i].parse(text);
} catch (Exception e) {
results[i] = e;
}
}
Now you can go through the results:
for (Object result : results) {
if (result instanceof Exception)
System.out.println("Error: " + result);
else
System.out.println("Parsed as " + result.getClass().getSimpleName() + ": " + result);
}
Output
Error: java.lang.NumberFormatException: For input string: "45.8"
Parsed as Double: 45.8
Error: java.lang.NumberFormatException: For input string: "45.8"
Parsed as BigDecimal: 45.8
Or put the parsed objects and the exceptions into two different lists. Up to you.

You can do something like this:
interface Parser {
Number parse(String);
}
class IntegerParser implements Parser {
#Override
public Number parse(String) {
// implementation here
}
}
class FloatParser implements Parser {
}
List<Parser> parsers = asList(new FloatParser(), new IntegerParser(), ...);
Number result = null;
List<NumberFormatException> exceptions = new ArrayList<>();
for (Parser parser : parsers) {
try {
result = parser.parse(stringToParse);
break;
} catch (NumberFormatException e) {
exceptions.add(e);
}
}
if (result != null) {
// parsed ok with some parser
// probably discard exceptions
} else {
// show exceptions from the list
}

Try this:
public static void test() {
final String num = "1.0";
final ArrayList<Object> listofResults = new ArrayList<>();
final java.util.function.Function<String, ?>[] parseMethods = new java.util.function.Function[3];
parseMethods[0] = Integer::parseInt;
parseMethods[1] = Float::parseFloat;
parseMethods[2] = Integer::parseInt;
int[] badIndeces = IntStream.range(0, parseMethods.length).map(i -> {
try {
listofResults.add(parseMethods[i].apply(num));
return -i-1;
} catch (NumberFormatException exc) {
return i;
}
}).filter(i -> i >= 0).toArray();
for (int element : badIndeces) {
System.out.println(element);
}
}

Return statement doesn't break out of block, even though condition is true

This is a simple program to check if a number if Fibonnacci. I have a mysterious bug: the "return true" statement isn't triggered. Instead, "hi" will be printed many times. Return should break out of the method, does anyone have insight as to why it's not? Thanks!
import java.util.*;
public class Solution {
public static boolean listFibs (long oldestFib, long oldFib, long input) {
long newFib = oldestFib + oldFib;
while (newFib < Math.pow(10,10)) {
if (newFib == input) {
System.out.println("hi");
return true;
}
listFibs(oldFib, newFib, input);
}
return false;
}
public static void main(String[] args) {
/*Scanner in = new Scanner(System.in);
int testCases = in.nextInt();
for (int i = 0; i < testCases; i++) {
int a = in.nextInt();
System.out.println("A= " + a);
System.out.println(listFibs(0, 1, a));
}*/
System.out.println(listFibs(0, 1, 5));
}
}

Due to the recursion there are many incarnations of listFibs. The return just leaves one of them.
In the example given, you get the following calls:
listFib(0,1,5)
listFib(1,1,5)
listFib(1,2,5)
listFib(2,3,5)
-> true
listFib(2,3,5) // called again due to the loop
-> true
listFib(2,3,5) // called again due to the loop
-> true
listFib(2,3,5) // called again due to the loop
-> true
listFib(2,3,5) // called again due to the loop
...

actually, if "hi" is printed many times, the return statement must be executed the same time. if you install a break point in that return statement, you will see.
your function is a recursion, and "listFibs" will be called many times.

Print values of all 3 variables in the method and you will know what's wrong. You are using recursion, see how many times it's being called.
Also, after call to listFib, execution will go to while loop again. You need to say return listFibs at least. Between your listFibs and while loop condition, nothing is changing. 2,3,5 are being found again and again.
see http://ideone.com/1d440f

You are one step short... The recursive call doesn't do anything with the results you get from listFibs, so the program sees something like this:
while (newFib < Math.pow(10,10)) {
if (newFib == input) {
System.out.println("hi");
return true;
}
true //or false
}
Try adding this extra little IF statement. Once a true result is found it will be passed back up the chain and out of the function.
while (newFib < Math.pow(10,10)) {
if (newFib == input) {
System.out.println("hi");
return true;
}
if listFibs(oldFib, newFib, input){
return true;
}
}

Continue keyword in recursion

I have come across the below code while searching some answers.
public static void recurse(Scanner in, HashMap<String, Integer> oldMap) {
HashMap<String, Integer> map = null;
if (oldMap == null)
map = new HashMap<String, Integer>();
else
map = new HashMap<String, Integer>(oldMap);
while (in.hasNext) {
String s = in.nextLine();
if (s.startsWith("[")) {
recurse(in, map);
continue;
}
if (s.startsWith("]")) {
break;
}
String[] split = s.split(" ");
if (s.startsWith("print")) {
System.out.println(map.containsKey(split[1]) ? map.get(split[1]) : 0);
continue;
}
int x = 0;
try {
x = Integer.parse(split[1]);
} catch (Exception e) {
x = map.containsKey(split[1]) ? map.get(split[1]) : 0;
}
map.put(split[0], x);
}
}
Can somebody please explain me , why the person has used continue just after recursive call. It seems to be that the continue will not be processed because each time the recursion call will be processed.

It's true that the recursive call will be processed — but then, eventually, the recursive call will return. (Unless it either raises an exception or enters an infinite loop, that is.) After the recursive call returns, the continue statement is executed.
It might help you to play with a simpler example of recursion:
public void printOneToN(int n) {
if(n > 1) {
printOneToN(n - 1);
}
System.out.println(n);
}
As you can see by running (say) printOneToN(10), after each recursive call, control returns to its caller. A recursive call does not replace its caller.

continue has nothing to do with the recursive call; its effect is to skip the rest of the contents of the while loop and go straight back to in.hasNext().

Looping my list so that runs through and combines the whole list

I am in a beginning class for programming and try to combine 2 lists to make one list, putting the new list in numerical order. The part I am having trouble with is, allowing the code to loop, repeating the steps so that it runs through the total original loops to complete the final list which is a combination of all the numbers from the original lists. Any guidance for the loop would be appreciated. Thank you.
import inClass.list.EmptyListException;
import inClass.list.List;
public class InitialLists {
public static void main(String[] args) {
List<Integer> intObject1 = new List<Integer>();{
intObject1.insertAtFront(25);
intObject1.insertAtFront(19);
intObject1.insertAtFront(3);
intObject1.print();}
List<Integer> intObject2 = new List<Integer>();{
intObject2.insertAtFront(120);
intObject2.insertAtFront(1);
intObject2.print();}
List<Integer> combinedList = new List<Integer>();
int object1 = intObject1.removeFromBack();
int object2 = intObject2.removeFromBack();
while(intObject1.removeFromBack() != null && intObject2.removeFromBack() != null){
try {
{
if (intObject1.removeFromBack() > intObject2.removeFromBack()) {
combinedList.insertAtFront(object2);
intObject1.insertAtBack(object1);
}
else if (intObject2.removeFromBack() < intObject1.removeFromBack()) {
combinedList.insertAtFront(object1);
intObject2.insertAtBack(object2);
}
else if (intObject1.removeFromBack() == intObject2.removeFromBack()) {
combinedList.insertAtFront(object1);
}
}
combinedList.print();
object1 = intObject1.removeFromBack();
object2 = intObject2.removeFromBack();
} // end try
catch (EmptyListException emptyListException) {
emptyListException.printStackTrace();
} // end catch
} //end while
} // end main
}// end class

What about:
List<Integer> combinedList = new ArrayList<Integer>();
combinedList.addAll(intObject1);
combinedList.addAll(intObject2);
Collections.sort(combinedList);
Or am I missing something?

To merge two files / lists / streams you need a loop that looks a bit like this
WHILE NOT FINISHED
GET SMALLEST VALUE FROM INPUTS
APPEND SMALLEST VALUE TO OUTPUT
So how will you know that you are finished?
How will you get the smallest of the next item in each list?
The code I have written above is called pseudocode; it is a way of describing the steps of an algorithm. Keep expanding each step until you have pseudocode that you can implement in your chosen language, in this case Java.
Hope that helps ...

I guess your problem is because of possible uneven size of two lists. Try putting while condition as below:
Integer object1 = intObject1.removeFromBack();
Integer object2 = intObject2.removeFromBack();
while(object1 != null || object2!= null){
if(object1 ==null){
//safe to assume object2 is not null as both not null together (that is the termination condition)
combinedList.insertAtFront(object2);
}else if(object2 ==null){
//safe to assume object1 is not null as both not null together (that is the termination condition)
combinedList.insertAtFront(object1);
}else{
//put you normal condition of handling object1 and object2 being not null
if (object1.intValue() > object2.removeFromBack()) {
combinedList.insertAtFront(object2);
intObject1.insertAtBack(object1);
}
else if (object2.intValue() < object1.intValue()) {
combinedList.insertAtFront(object1);
intObject2.insertAtBack(object2);
}
else if (object1.intValue() == object2.intValue()) {
combinedList.insertAtFront(object1);
}
}
object1 = null;
object2 = null;
try{
object1 = intObject1.removeFromBack();
}catch (EmptyListException emptyListException) {
//do nothing
} // end catch
try{
object2 = intObject2.removeFromBack();
}catch (EmptyListException emptyListException) {
//do nothing
} // end catch
}
Also please note: There are better way of doing the merge of two sorted list elements. This approach is advised in light of your little known custom List class.

Understanding the 'finally' block

I've written seven test cases for understanding the behavior of the finally block. What is the logic behind how finally works?
package core;
public class Test {
public static void main(String[] args) {
new Test().testFinally();
}
public void testFinally() {
System.out.println("One = " + tryOne());
System.out.println("Two = " + tryTwo());
System.out.println("Three = " + tryThree());
System.out.println("Four = " + tryFour());
System.out.println("Five = " + tryFive());
System.out.println("Six = " + trySix());
System.out.println("Seven = " + trySeven());
}
protected StringBuilder tryOne() {
StringBuilder builder = new StringBuilder();
try {
builder.append("Cool");
return builder.append("Return");
}
finally {
builder = null;
}
}
protected String tryTwo() {
String builder = "Cool";
try {
return builder += "Return";
}
finally {
builder = null;
}
}
protected int tryThree() {
int builder = 99;
try {
return builder += 1;
}
finally {
builder = 0;
}
}
protected StringBuilder tryFour() {
StringBuilder builder = new StringBuilder();
try {
builder.append("Cool");
return builder.append("Return");
}
finally {
builder.append("+1");
}
}
protected int tryFive() {
int count = 0;
try {
count = 99;
}
finally {
count++;
}
return count;
}
protected int trySix() {
int count = 0;
try {
count = 99;
}
finally {
count = 1;
}
return count;
}
protected int trySeven() {
int count = 0;
try {
count = 99;
return count;
}
finally {
count++;
}
}
}
Why builder = null is not working?
Why does builder.append("+1") work whereas count++( in trySeven()) does not work?

Once you do the return, the only way to override that is to do another return (as discussed at Returning from a finally block in Java, this is almost always a bad idea), or otherwise complete abruptly. Your tests don't ever return from a finally.
JLS §14.1 defines abrupt completion. One of the abrupt completion types is a return. The try blocks in 1,2,3,4, and 7 abruptly complete due to returns. As explained by §14.20.2, if the try block completes abruptly for a reason R besides a throw, the finally block is immediately executed.
If the finally block completes normally (which implies no return, among other things), "the try statement completes abruptly for reason R.". In other words, the return initiated by the try is left intact; this applies to all your tests. If you return from the finally, "the try statement completes abruptly for reason S (and reason R is discarded)." (S here being the new overriding return).
So in tryOne, if you did:
finally {
builder = null;
return builder;
}
this new return S would override the original return R.
For builder.append("+1") in tryFour, keep in mind StringBuilder is mutable, so you're still returning a reference to the same object specified in the try. You're just doing a last minute mutation.
tryFive and trySix are straight-forward. Since there is no return in the try, the try and finally both complete normally, and it executes the same as if there was no try-finally.

Let's start with use case you'll see more often - you have a resource that you must close to avoid a leak.
public void deleteRows(Connection conn) throws SQLException {
Statement statement = conn.createStatement();
try {
statement.execute("DELETE * FROM foo");
} finally {
statement.close();
}
}
In this case, we have to close the statement when we're done, so we don't leak database resources. This will ensure that in the case of an Exception being thrown, we will always close our Statement before the function exits.
try { ... } finally { ... } blocks are meant for ensuring that something will always execute when the method terminates. It's most useful for Exception cases. If you find yourself doing something like this:
public String thisShouldBeRefactored(List<String> foo) {
try {
if(foo == null) {
return null;
} else if(foo.length == 1) {
return foo.get(0);
} else {
return foo.get(1);
}
} finally {
System.out.println("Exiting function!");
}
}
You're not really using finally properly. There is a performance penalty to this. Stick to using it when you have Exception cases that you must clean up from. Try refactoring the above to this:
public String thisShouldBeRefactored(List<String> foo) {
final String result;
if(foo == null) {
result = null;
} else if(foo.length == 1) {
result = foo.get(0);
} else {
result = foo.get(1);
}
System.out.println("Exiting function!");
return result;
}

The finally block is executed when you leave the try block. The "return" statement does two things, one it sets the return value of the function and two it exits the function. Normally this would look like an atomic operation but within a try block it will cause the finally block to execute after the return value was set and before the function exits.
Return execution:
Assign return value
run finally blocks
exit function
Example one (primitive):
int count = 1;//Assign local primitive count to 1
try{
return count; //Assign primitive return value to count (1)
}finally{
count++ //Updates count but not return value
}
Example two(reference):
StringBuilder sb = new StringBuilder();//Assign sb a new StringBuilder
try{
return sb;//return a reference to StringBuilder
}finally{
sb.append("hello");//modifies the returned StringBuilder
}
Example three (reference):
StringBuilder sb = new StringBuilder();//Assign sb a new StringBuilder
try{
return sb;//return a reference to StringBuilder
}finally{
sb = null;//Update local reference sb not return value
}
Example four (return):
int count = 1; //assign count
try{
return count; //return current value of count (1)
}finally{
count++; //update count to two but not return value
return count; //return current value of count (2)
//replaces old return value and exits the finally block
}

builder = null and builder.append("+1") are working. It's just that they're not affecting what you're returning. The function returns what the return statement has, regardless of what happens afterward.
The reason there is a difference is because builder is passed by reference. builder=null changes the local copy of builder. builder.append("+1") affects the copy held by the parent.

Why builder = null is not working?Because you are setting the local reference to null which will not change the content of the memory. So it is working, if you try to access the builder after finally block then you'll get null.Why builder.append("+1") work? Because you are modifying the content of the memory using the reference,that's why it should work.Why count++ does not work in testFive()? It is working fine with me. It outputs 100 as expected.

Consider what the compiler is actually doing for the return statement, for instance in tryOne(): it copies a reference to builder back to the calling function's environment. After it's done this, but before control goes back to the calling function, the finally block executes. So you have something more like this, in practice:
protected StringBuilder tryOne() {
StringBuilder builder = new StringBuilder();
try {
builder.append("Cool");
builder.append("Return");
StringBuilder temp = builder;
return temp;
} finally {
builder = null;
}
}
Or, in terms of the order that statements actually get executed (ignoring possible exceptions, of course), it looks more like this:
protected StringBuilder tryOne() {
StringBuilder builder = new StringBuilder();
builder.append("Cool");
builder.append("Return");
StringBuilder temp = builder;
builder = null;
return temp;
}
So setting builder = null does run, it just doesn't do anything useful. However, running builder.append("something") will have a visible effect, since both temp and builder refer to the same (mutable) object.
Likewise, what's really happening in trySeven() is something more like this:
protected int trySeven() {
int count = 0;
count = 99;
int temp = count;
count++;
return temp;
}
In this case, since we're dealing with an int, the copies are independent, so incrementing one doesn't affect the other.
All that said, the fact remains that putting return statements in a try-finally block is quite clearly confusing, so if you've got any kind of choice in the matter, you'd be better off rewriting things so that all your return statements are outside any try-finally blocks.