Are exceptions really for exceptional errors? [closed]

Question

It's my understanding that common wisdom says to only use exceptions for truly exceptional conditions (In fact, I've seen that statement here at SO several times).

However, Krzysztof Cwalina says:

One of the biggest misconceptions about exceptions is that they are for “exceptional conditions.” The reality is that they are for communicating error conditions. From a framework design perspective, there is no such thing as an “exceptional condition”. Whether a condition is exceptional or not depends on the context of usage, --- but reusable libraries rarely know how they will be used. For example, OutOfMemoryException might be exceptional for a simple data entry application; it’s not so exceptional for applications doing their own memory management (e.g. SQL server). In other words, one man’s exceptional condition is another man’s chronic condition.

He then also goes on to say that exceptions should be used for:

• Usage errors
• Program errors
• System failures

Considering Krzysztof Cwalina is the PM for the CLR team at MS I ask: What do you think of his statement?

Answer 1

This sounds over-simplistic, but I think it makes sense to simply use exceptions where they are appropriate. In languages like Java and Python, exceptions are very common, especially in certain situations. Exceptions are appropriate for the type of error you want to bubble up through a code path and force the developer to explicitly catch. In my own coding, I consider the right time to add an exception when the error either can't be ignored, or it's simply more elegant to throw an exception instead of returning an error value to a function call etc.

Some of the most appropriate places for exceptions that I can think of offhand:

• NotImplementedException - very appropriate way of designating that a particular method or function isn't available, rather than simply returning without doing anything.
• OutOfMemory exceptions - it's difficult to imagine a better way of handling this type of error, since it represents a process-wide or OS-wide memory allocation failure. This is essential to deal with, of course!
• NullPointerException - Accessing a null variable is a programmer mistake, and IMO this is another good place to force an error to bubble to the surface
• ArrayIndexException - In an unforgiving language like C, buffer overflows are disastrous. Nicer languages might return a null value of some type, or in some implementations, even wrap around the array. In my opinion, throwing an exception is a much more elegant response.

This is by no means a comprehensive list, but hopefully it illustrates the point. Use exceptions where they are elegant and logical. As always with programming, the right tool for the right job is good advice. There's no point going exception-crazy for nothing, but it's equally unwise to completely ignore a powerful and elegant tool at your disposal.

Answer 2

For people who write frameworks, perhaps it's interesting.

For the rest of us, it's confusing (and possibly useless.) For ordinary applications, exceptions have to be set aside as "exceptional" situations. Exceptions interrupt the ordinary sequential presentation of your program.

You should be circumspect about breaking the ordinary top-to-bottom sequential processing of your program. The exception handling is -- intentionally -- hard to read. Therefore, reserve exceptions for things that are outside the standard scenarios.

Example: Don't use exceptions to validate user input. People make input mistakes all the time. That's not exceptional, that's why we write software. That's what if-statements are for.

When your application gets an OutOfMemory exception, there's no point in catching it. That's exceptional. The "sequential execution" assumption is out the window. Your application is doomed, just crash and hope that your RDBMS transaction finishes before you crash.