Permutation and combination calculator
Catch specific exceptions, avoid Exception

This is a good example where it's a bad idea to catch Exception:


try {
    total = Integer.parseInt(entry);
    return Integer.toString(permutate(total));
} catch(Exception e) {
    return "Invalid input";
}



The catch here was clearly intended for parsing errors,
but what if something goes wrong in permutate due to some bug?
The bug will get masked under an "Invalid input" response.

It's good to catch the most specific exception type.
It also communicates to readers of the code what exactly can go wrong with the code.

Limit the body of the try block as much as possible

Still on the previous example,
catching NumberFormatException is a good first step, but not enough.
You should also move the permutate call outside the try-catch block,
to avoid catching NumberFormatException thrown by permutate instead of the Interger.parseInt(entry) line.

Sure, if you look at the implementation of permutation this is impossible now,
but who knows, you might add a change later.
In general, it's not practical to verify all calls going out from a try block for potential hidden bugs.
It's a lot easier to just move such calls outside of the try block
and eliminate all suspicions and potential future bugs.

Avoid repeated logic

The computePermutation method has some duplication of logic in the parsing of total.
You could rearrange the code to do it only once.

Avoid duplicated string literals

The message "Invalid input." appears multiple times.
It would be good to move it to a constant.

Check empty strings with isEmpty

Instead of limit.length() == 0,
a more idiomatic way is limit.isEmpty().