Articles in Variable Names

They add little to no value in most cases, but make the code longer to read.

Usually, I'd rarely have a the need for the distinction between a "a" or "the" in the flow of a function, so it doesn't make sense to use articles.

It's a formal programming language and I am fine with it not reading exactly like a natural language. In fact, it's probably better this way, not everything's necessarily so great about natural languages.

There are a few cases where readability can benefit from using articles though, for instance if you want to implement a checker for a "is a" relationship with a method signature like boolean isA(Object o, Class<?> cl) ^{(I'm not advocating this to be a good idea)}.

Hard-Coded Strings

It depends on whether you plan to reuse them or not, and whether that reuse is driven by semantics (and not just the fact that the String has the same content in different places) and spread across multiples classes or sub-systems.

To that extent, I usually use these rules:

1. If you have the same string multiple times and it has the same meaning acros multiple classes, then extract to constants in an interface.

2. If you have the same string multiple times within a single class and it has the same meaning within that class, then extract to constants within the class.

3. If you have only a few number of repetitions of as tring, or they just happen to be identical but aren't guaranteed to always be in the future, then I'd leave them inlined.

4. If any of the above would render maintenance difficult, screw rules 1 to 3 and do whatever works best for you.

Of course, make sure that the constant's name makes the code as semantically valid as the string it holds. That also applies for other things that aren't strings (like Predicates, for instance).

It looks like the intent is to try 5 times, logging the problem each time. If none of the attempts succeed, give up after 5 tries. I'll label this the scaffold, and I'll call the thing to try 5 times the core functionality.

Let's look at the two versions with reference to some coding guidelines from around the web. For simplicity, I'll call versions R for the recursive version and S for the non-recursive version because it has separate code for the scaffold and the core functionality.

S conforms better to SOLID principles than R, in particular to the single responsibility principle, but also to some extent to the Liskov substitution principle.

• single responsibility - separating the scaffold from the core functionality allows each to concentrate on their own intricacies.; and

• Liskov substitution - separating out the core functionality allows other core functionality to be used with the same scaffold, as you observe.

Your non-recursive version embodies the coding intent more clearly and has less mingling between core functionality and exception code. This helps with code review and maintenance. To improve on it, you can consider using another of the SOLID principles: dependency inversion. Instead of having the generic executeProcess depend on the concrete someMethod, add a call-back as a parameter toexecuteProcess and call executeProcess with (an encapsulated form of) someMethod. This allows you to put executeProcess into a generic library rather than copy-paste-modify it for each new someOtherMethod that might be introduced later.

Mingling business logic with exception handling is the first warning in this list of best practices for exception handling. Even the sleep can be considered part of the clean-up, perhaps relegated to a finally block or placed outside the exception mechanism altogether.

Another issue with R is that the recursion (into the code that threw the exception) occurs before the exception is fully handled.

Your refactored version is the better option of the two.