What is 'exceptional'? [closed]

Answer 1

Well, Exceptional programming case is one which deviates the program flow from normal stream and it might be due to:

::A h/w of s/w fault that programmer cannot handle in given situation. Programmer may be not sure what to do in those case and he left it to the user or tool/library which invokes this code. ::Even programmer might not be sure the exact environment in which his code will be used and hence it is better to leave the error handling to the one who uses the code.

So exceptional case with a program might be is to use it uncommon environment or with uncommon interactions. Again uncommon interactions and unknown environments refers to the designers point of view. So deviation from Normal is exceptional and again it is based on the point of view and context of the programmer.

Is it too round and round?:D

Answer 2

I'm not going to get into the holy war of whether exceptions ought to be used as flow control or not, but rather I'm going to focus on what an exceptional event is...

Oracle, in the context of Java, defines an exceptional event this way:

An exception is an event, which occurs during the execution of a program, that disrupts the normal flow of the program's instructions.

Of course, this definition applies to exceptions in general, not just in Java.

The key here is "disrupts the normal flow". In other words, the program fails in such a way that it can't complete its instructions.

A program has a defined range of functionality. When all your program's functionality is accounted for (including handling of invalid input), anything that is left over is an exception and likely a bug.

I believe there are two kinds of exceptions:

1. Bugs, which are introduced into the program by the programmer.
2. Uncontrollable situations, like someone else said, pulling the power plug. Of course, the program wouldn't get to throw an exception in this case, but if it could, it would. Other exceptions might be some sort of failure within the OS or network that the program relies on.

For instance: A program ought to handle invalid input from users as part of its normal flow, because users will of course give you invalid input at some point. This isn't a disruption because the program's functionality should be able to parse input and see if it's valid.

However, if a programmer somehow allows null to be passed to a method that isn't supposed to accept null, then that's an exception. The method's behavior is undefined for values of null. While it's a gray area, the reason I don't necessarily consider this invalid input like the above example is because the method has a certain spec, and by coding something into the program that passes a value violating that spec, it's a bug.

Answer 3

And another good rule of thumb - never use exceptions to catch conditions that you can catch in code.

For example if you have a method divides 2 variables, don't use an exception to catch divide by zero errors, instead do the necessary checks beforehand.

Bad code example:

float x;
try {
x = a / b;
{
catch (System.DivideByZeoException) {
x = 0;
}

Good code example:

if (b == 0)
return 0;

Exceptions are generally expensive.

Answer 4

I disagree with the other answers about something needing to be "exceptional" to warrant an "exception". I say "exceptional" is any time you want to break the normal flow of control in the way you can by throwing an upward-propagating object.

Exceptions are a language feature. They're a means to an end. They aren't magical. Like any other feature, when you use them should be guided by when you need what they can provide, not by what they are called.

Answer 5

When someone rips out the power chord, that is exceptional, most of the other situations are expected.

Answer 6

It's exceptional if:

1. It is a failure condition. AND

2. It happens infrequently and unexpectedly. AND

3. There is no better mechanism for reporting it.

edit

Stealing blatantly from Dan Weinreb's blog entry, which Ken posted about here, I'd like to offer the following summary of what exceptions are about.

1. The method's contract defines how (and whether) unusual conditions (ie. failures) are signaled. If the method says something is an exception, it just is. Of course, this leaves open the question of how we should design the contract.

2. Exceptions have the benefit of not requiring any checking by the caller, as well as naturally bubbling up until they are caught by something able to handle them. They can also contain significant detail, user-readable text and stack traces. These features make them ideal for failure cases that prevent further processing but are not predictable or common, or where explicit error-handling would be disruptive to code flow. They are especially good for errors that "should never happen" but are catastrophic in effect (such as a stack overflow).

3. Flags, error codes, magic values (NULL, nil, INVALID_HANDLE, etc.) and other return-based mechanisms do not commandeer flow, and are therefore better suited for cases that are common and best handled locally, especially those where the failure can be worked around. As they operate by convention and not fiat, you cannot count on them to be detected and handled, except that an invalid value may be designed to cause an exception if actually used (such as an INVALID_HANDLE being used to read).

4. When using exceptions in robust code, each method should catch unexpected exceptions and wrap them inside an exception from the contract. In other words, if your method does not promise to throw NullReferenceException, you need to catch it and rethrow it inside something more general or specific. They're called exceptions, not surprises!