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.