//The jre does not seem to provide the equivalent of std::pair
// or any other Implementation of a Tuple, the closest thing
// i could find is a internal class to Map
// a Entry and it is a Interface…
//So without further ado basic Pair implementation,
// because i just cannot live without it
public final class Pair
{
private F mFirst;
private S mSecond;

public Pair(final F inFirst, final S inSecond)
{
super();

mFirst = inFirst;
mSecond = inSecond;
}

public F first()
{
return mFirst;
}

public S second()
{
return mSecond;
}

public void setFirst(final F inFirst)
{
mFirst = inFirst;
}

public void setSecond(final S inSecond)
{
mSecond = inSecond;
}
}

public static void main(String[] args) {
final CustomerRepo r = new CustomerRepo();
final Customer c = getCustomer2(r, 1337);
}

public static Customer getCustomer2(CustomerRepo r, int id) {
try {
return r.getCustomer(id);
} catch (CustomerNotFoundException e) {
return r.createCustomer();
}
}
}

you could also create that method in anonymous class like mullet wrote, but you wouldn\’t have to create non-final variables.

final Customer c = new Object() {
Customer value; {
try {
value = repo.getCustomer(1);
} catch (CustomerNotFoundException e) {
value = repo.createCustomer();
}
}}.value;

Essentially we simply hide the temporary variable \’value\’ by wrapping it up in an object. I\’m not that its a better solution to your, but I offer it as an alternative.

Advantages:
1. Simpler for the person who coded it to understand, since it looks more like a normal try/catch block.
2. If the \’getCustomer\’ method throws a RuntimeException then you will simply get it straight away, where as it gets wrapped in another RuntimeException with your solution.
3. No requirement for reflection hacks, that have potentially negative performance impact, and would require more knowledge on behalf of the reader.
4. Easier to Extend – chaining TryCatch instances would result in some pretty horrific nested inner class declarations, though I suppose one could build a TryCatch2, TryCatch3 etc. and abstract some of the mess a bit. In my solution you simply add another catch block.

Disadvantages:
1. Your approach encourages better code reuse, since you have built a generic try/catch abstraction, rather than requiring a one-off construct.
2. Uncertain where to place the braces. My placement of braces above would break the code style guidelines in many projects, but reflects my intuition that \’value\’ is really part of the method, and being wrapped in an object is simply there to hide the state. Which is correct is really up to you.
3. Anonymous Constructors look weird in Java.
4. The introduction of temporary state is still a crime against humanity, even if it is cleanly abstracted.

<< >>

also at the bottom!

It would make a lot of sense…

Everything else seems to be working fine!!!

It’s going to be wonderful when this is up

Good Job

Good work, thank you