If you don’t want an exception, you could use TryGet pattern:

Drink drink;
if(vendingMachine.TryGetDrink(out drink))
{
// we got a drink!
}

Andy said: “I want my code to fail fast. If I don’t get a Drink, I want my code to tell me why.” As said before, both approaches can co-exist, and now you described a situation in which you shouldn’t be using null-refs! Perhaps solutions such as response-types (normal flow with additional info), or exceptions (exception or error flow optionally with yet more info).

Examples for returning nulls (sure we have alternatives):
1- getDefaultDrinkOrNull( ) if no-default-drink is considered a typical response and we prefer handling it in normal flow, fortunately designer has cleared all potential confusion by proper naming.
2- in a linked-list I may like getNext( ) return next object or null for the trail gifting more simplicity for iterations.

I think the “drink” example is a bit too generic! We could better be discussing null issues by real-world scenarios. For example:
A- If the Drink type is actually a Customer in a web scenario then returning response-types or exceptions are probably better approaches.
B- In a getTempFile( ) : File I might go for exceptions if it cannot return a temp file!
C- And for getActiveUser in a security service I might prefer returning null for indicating no-active-user message – however, I myself have designed security services in which active users were returned by response-types and some specific exceptions too. My mind wasn’t changed, they were just proper solutions for their unique requirements.

All I try to say is, we should NOT replace null-handling, BUT we may discuss a particular case in which null-handling is not the best.

BUT exceptions are beautiful if it’s really considered an “exception” and should pick an alternate flow instead of the regular normal flow. For instance, designer of openFile( ) method MIGHT decide to throw an exception if invalid filename supplied!

Good design employs a mixture of both types; the point is to properly decide what should be considered the “normal” flow and what should be the “exception” or “error” flow! The rest is THE ART OF DESIGN… in summary I stand for proper use of null-handling and exception-flows, not eliminating any of them…

The blinkNotEnoughMoneyLight() would live in the vending machine. I use it to bring up the point of how the code is intended to react to being able to give out a drink – blinking a light to the user indicating more money is needed.

There is no contract that there should always be a drink from a vending machine. There is probably a business rule that says that once the needed money has been given. The value of null would only given out when that precondition is violated, which would only happen from programmer error.

@eckes: I’m thinking that we might move to a DrinksChute object, which is a collection, but that’s not the way it is at the moment

@jeremy: Null Object is a possibility, but it depends on the planned usage of the returned object. In this case, the Drink has no behaviour, so it doesn’t make sense to have a NullDrink. If we can’t return a real Drink, I want to know why

@mark: These exceptions are unchecked I’ll post some thoughts on that soon.
Null Object is useful where we are expecting some behaviour from the returned object rather than just existence.
A quick example that I thought of would be a NullTransaction on a BankAccount. This would have no effect on the balance of the account, but may be used to make a note in the transaction history.

@sarah: I see where you’re coming from, and there are many possible workarounds, but I have asked the VendingMachine for a Drink. I don’t want my clients to have to worry about DrinkResponses that may or may not have a drink, which then has to be extracted. The DrinkChute collection would be acceptable, but it’s not the simplest thing in this example.

@all: This is a contrived example, but the exceptions aren’t really being used for business logic. They are unchecked, so there is no reason to catch them unless you want to handle the situation. The system fails fast with a clear reason as to why and where the problem occured.

Obviously, this is all just my opinion
I’ll defend my choice of using Exceptions with this:
The client code needs a Drink to proceed, it makes no sense to continue running if we do not receive a drink. If we use any of the other solutions, we still have to check to see if it’s ok to proceed (did we get our drink?). With the Exception route, the application stops and tells you why, without additional burden on the client.