Purposes of introducing exception handling mechanism

Question

I know from wikipedia for example that exception handling is used in an application to custom handle certain errors in a fail-safe manner. However, I'm not sure why in those cases in general the developer would want the user to experience the error to be reset in a fail-safe manner. The following is a pseudocode of what I'm doing (but I'm not sure what's the biggest purpose of the exception in this case).

while(not exitting the program)
{
    try
    {
        Perform(); // perform custom calculation by calling
    }
    catch(int e)
    {
         sort out what e stands for
         reset the variables of the object
    }
    catch(...)
    {
         print message
         reset the variables of the object
    }
}

It would be great to hear some comments. Thanks in advance.

Answer 1

Exception Handling is generally considered much better than the alternatives.

i.e. ignoring errors or checking retrun codes.

Generally speaking there are three(or four) things you can do when you catch an error.

1 - handle it/ignore it. If you decide the exception does not interfere with the correct running of your program then this is the correct action. e.g. End of File type exceptions.

2 - Try an alternative. e.g. if "file not found" then create a new file containing default values and open it.

3 - Transalate the technical error into a user understandable error and notify the user. e.g. instread of the 30 line com.java.jdbc SQL exception ... message You tell the user 'No Price information for the requested product code'

4 - In the Java world only -- and everybody hates having to do this -- pass the exception through to the calling process.

Number 4 is especially annoying as one of the main advantages of exception handling from a programming style viewpoint is the separation of fiddly error handling code from the "real" that does your business logic, the tedious process of declaring, catching and throwing exceptions which you do not want to handle in your code leads to a massive amount of distracting clutter in the average java program.

Answer 2

Exception handling doesn't really have anything to do with the user, it is about separating error handling logic from "normal" logic. Languages like C++ and Java have constructs like the following:

try {
  makeDough();
  bakeBread();
  eatIt();
}
catch(RecipeNotFollowed error) {
  tellSomeoneToThrowTheDoughOutAndStartOver();
}
catch(OvenNotOn error) {
  tellSomeoneToTurnTheOvenOn();
}

The try section is for "normal" logic. The catch section for error handling. They demarcate the two kinds of logic and simplify error handling. Consider the alternative with error codes:

boolean doughMadeCorrectly = makeDough();

if(!doughMadeCorrectly) {
  tellSomeoneToThrowTheDoughOutAndStartOver();
  return false;
}

boolean breadHotAndCrispy = bakeBread();

if(!breadHotAndCrispy) {
  tellSomeoneToTurnTheOvenOn();
  return false;
}

eatIt();

return true;

A bit of a silly example, but I think it shows the big differences between the two main ways of handling errors. One way the two kinds of logic are grouped together, the other way they are interspersed. I think exception handling is much cleaner.

Answer 3

The idea of exception handling is not suppressing of errors, it's about making the best out of a bad situation.

Let's take a minimalistic browser application for example. And let's say you are trying to open a web page from a server, which is currently not reachable.

At the lowest level you might get a socket exception, because the remote server doesn't accept any connection (depending on the framework). Now you have essentially two choices:

1. Let the browser application die, together with a generic error message provided by the operating system.
2. Handle the error and make the best out of it: Show an error page and enable the retry button.

In a way the error is not really ignored, but it's not allowed to crash your application either.

The browser example is a typical situation: You have some low-level error but you just don't allow it to crash your appliction. Instead your application can recover from it and perhaps provide alternative actions.