Instead, it will have an exception to deal with (or not). If you
can do something useful in the way of report or rescue, catch the
exception and do so. If not, let the exception propagate upwards
(if necessary wrap it or add a throws declaration).

Not only clunky but unnecessary.

    One approach, as you've outlined, is to return a special
value to tell the caller the request was unsuccessful:

    Loan loan = bank.getLoan(amount, purpose);
    if (loan == null)
       System.out.println("Buncha tightwads!");
    else
       System.out.println("Party time!");

    Another is to throw an exception and let the caller catch
it (or pass it outwards to a still higher-level caller):

    try {
       Loan loan = bank.getLoan(amount, purpose);
       System.out.println("Party time!");
    }
    catch (LousyCreditRatingException ex) {
       System.out.println("Buncha tightwads: " + ex);
    }

    Which is better?  It depends largely on the expected course
of events, on whether the sorry-no-object case is considered
"exceptional" or "routine."  In the illustration above, a bank's
decision to deny a loan request would probably be thought of as
a "normal" possible outcome, so the first approach would probably
be favored.  But if we change the nouns and verbs a little:

    try {
       License license = driver.demandLicense();
       radio.checkForRapSheet(license.getNumber());
    }
    catch (UnlicensedDriverException ex) {
       System.out.println("Keep your hands in view "
           + "and step out of the car.  You in a heap "
           + "of trouble now, kid.");
    }

... the sorry-no-object outcome might be considered "abnormal"
or "exceptional," and the second approach would probably be better.

    There are also combined approaches, using special values for
"normal failures" and exceptions for "weird cases:"

    try {
       Loan loan = bank.getLoan(amount, purpose);
       if (loan == null)
           System.out.println("Buncha tightwads!");
       else
           System.out.println("Party time!");
    }
    catch (BankWentBrokeException ex) {
       System.out.println("Bank failed! " + ex);
    }

    The long and short of all this is that there is no "one best
way" that fits all situations equally well.  You need to exercise
some judgment as to what cases are "normal" and "exceptional,"
and choose accordingly.

Why not throw an exception to the class that wanted the object if the
object cannot be built?

Look closely at the inter-class interface. Does the caller know about
the IO activities? If so, it may make sense to just let the IO
exceptions flow back to the caller.

In other cases, the caller does not know or care about IO. Then you
could define an exception of your own that explains the failure to
create the object in terms that make sense for that interface. You can
pass the IO exception to the Exception constructor so that no
information is destroyed.

The caller's code becomes:

try{
  SomeType o = interfaceMethod.result();
  // do things with o
}catch(YourExceptionWhatever e){
  // deal with not having o.
}

Patricia

   In addition to the other advice you've received here, you may want to
take a look at the Builder design pattern for inspiration:
http://en.wikipedia.org/wiki/Builder_pattern

   - Oliver