I use exceptions when there is no point in the current logic path continuing. In the VendingMachine example, my friend Liz was able to write a Swing GUI that caught the exception and displayed it as an error message on the LCD display. Quite a result!To do that with return flags, I’d have to check the return flag, and then probably return a return flag to my caller, who’d have to return a return flag to his caller… and so on and so on.

Also, out parameters, by their very nature require mutable state… Not for me, thanks.

This is a prime example of where a result flag + out params is appropriate.

bool GiveMeaDrink(out Drink)

So now you know if it’s safe or not off one call. If you need to know why give some way to get that info. But really you’re looking into the state of the vending machine at that point and it doesn’t really need to tell you since you already know you were supposed to provide the adequate amount of money first.

You could argue that it’s better to check state first then call. However that’s only partially successful since it would fail in a threaded environment.

however the point is Exceptions are “exceptional” (hense the name) not “normal” you didn’t give me enough money so you can’t have a drink is not exceptional in anyway. You just need to learn how to count your change better.

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…