Partner mating game

I say this is right because X might happen and Y modification to the code is possible in the future. More senior guy says the sorta similar thing, except along the lines "I'm right, you're wrong." Then I back off, b/c he is more senior.

Here I implement a method playMatingGameA(String). My more senior coworker provides alternative implementation playMatingGameB(String). Please, ignore how the main object fits into the grand scheme of things. The point is coding up a single method.

Problem description: an object of class Partner has to play a mating game. The input is a mating call. S/He takes a taxi, goes to a Bar or a Club or whatever, emits a mating call, flirts and mates. The playMatingGame() method isn't supposed to throw an exception or return a value. A string status variable is set instead.

String matingCall must be nonempty. The establishment (Bar) must find it appropriate.
A few method calls can throw exceptions/return nulls.

I'll conclude with my own thoughts, but comments from other engineers would be much appreciated.

```
interface MeatMarket
{
public Partner findPartner(String matingCall);

public boolean isMatingCallAllower(String call)
throws PartnerRejectionException;
} // e.g., Bar, Club, Church, etc.

class TaxiMeatMarketFactory
{
public static MeatMarket getMeSomePlaceFun()
throws RuntimeException; // I know, no need 2 declare
}

public abstract class Partner
{
String name;
// {get; set; justkiddingthisisjava;}

private String morningAfterFeeling;

// here B constructorz [skip]

// . . . and the methodz
public void flirt(Partner p)
throws PartnerRejectionException, ParnterNotSoberException;

public abstract void mate(Partner p)
throws PartnerWrongSpeciesException;

// The goal: with your given mating call, take taxi to a meatmarket
// find a partner, flirt then mate.
// No throwing up! No Exceptions!
//
// MUST return void and record

I agree explicitly checking for error conditions (instead of a general catching of Exception) and failing fast or returning early are usually good practices, as you have done in your method. Some people don't like the break in logic flow, but there's no reason to continue on and it avoids nesting of conditionals and/or other code blocks. Catching generic Exception is always a red flag for me -- sometime you have to do it, but usually there's a better way.

To simplify the catch blocks, you might want to consider making a superclass (say AbstractRejectionException) for all your custom exceptions that has an abstract getMorningAfterFeeling() method to allow the subclasses to return their own specific feelings. This would simplify many of your catch blocks into just this:

} catch (AbstractRejectionException e) {
    morningAfterFeeling = e.getMorningAfterFeeling();
    log.error(e);
}

Also, you are initially setting morningAfterFeeling to "Great", but checking for Good".equals(morningAfterFeeling. I'm assuming that was a typo.

StackExchange Code Review Q#5579, answer score: 2