And not only that, but also the fact that we should actually be using checked exceptions for everything, but there’s a big (but easily fixed) problem with the implementation of them in Java (and any other language for that matter in regards to regular unchecked exceptions). I also include a proposal for a solution by making a small language adjustment.
In a nutshell, checked exceptions should automatically be converted to unchecked (runtime) exceptions when they are not caught or rethrown. That way you almost exclusively deal with (throw and catch) checked exceptions (which I call functional errors) originating directly from the called function. Unchecked exceptions (which I call internal errors) are only to be caught at specific places in code (perhaps only the main() function) to log them and display a “Something went wrong, check the logs” message to the user.

Example: when calling login() I would like to catch UserNotFoundError and PasswordIncorrectError to display a useful error message on the login screen that the user should check the username and password and try again. I don’t care about any DatabaseNotFoundError, IoError, ConnectionLostError, etc. etc. because I can’t handle such errors originating from deeper functions called by the login function. Those are internal implementation details and need to be dealt with at another level in the application.

This is the link to the article:
http://blog.bitethecode.com/post/130259363012/exceptions-dont-excist

The pun in the title is intended.

I disagree (strongly) with the idea of exceptions being exceptional. They’re actually a half-arsed implementation of Lisp conditions (see Greenspun’s tenth rule)

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…