Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Second of all, I was wondering if anyone knew what the difference was between exceptions (in the realm of exception control flow) and Exceptions (such as used in Java).

But are they there to basically protect the system from crashing by terminating the user program?

share|improve this question

7 Answers 7

up vote 24 down vote accepted

Exceptions exist to allow Exception Handling, which can avoid crashes but more generally prevent unwanted or unpredictable system behavior. For instance if my program's connection to a database times out it's usually not going to crash the system, but if I was depending on data from the database an exception can allow me to treat this data-less situation differently than normal.

Say by default my program displays a page of data based on what was returned from the database--well crap, I have no data. Instead of presenting a messed up view or continuing a potentially invalid operation I can catch this exception and fall back to a different database, read from local data, ask the user for data or otherwise return the user or system to a safe state (presumably one that will not immediately cause the same exception!)

In addition in systems where user input could be the cause/solution to a problem, exceptions can let a user know detailed and helpful info about the problem. Instead of the too common "An unhandled exception occurred at..." or "Intimidating Error Message Straight from SQL" you can tell the user something helpful or at least understandable like "Could not connect to resource B."

share|improve this answer
5  
I feel this is the most accurate answer. Programs are finite state machines which do work. There are ways to break the machine by introducing bad data, which would cause it to malfunction. Exceptions are thrown to prevent this. Sometimes the machine can recover itself, but sometimes it cant. –  Andy Oct 15 '11 at 0:24

Exceptions were created to simplify error-handling. Without exceptions, error handling logic must be spread throughout an application. Any function that could possibly result in an error must somehow return an error status, and each call must be followed by a check for error. Often the caller can do nothing useful in case of error, and can only return an error itself. Half the application code may be devoted to error handling. Such code is extremely fragile. It is all too easy to leave out an error check and crash, or worse, return incorrect results due to an unnoticed error.

With exceptions, errors can be checked only at the point where they can be handled. Most application code can be written in straight-line fashion, since functions will either return a usable value or throw an exception.

share|improve this answer

The point of an exception should be to inform the user of exceptional circumstances. If something goes wrong with the system the program should know and be allowed to handle it *appropriately.

That said, no, an exception does not exist to prevent the system from "crashing". An exception it is letting me know there is a problem. How I proceed determines can determine if the system "crashes".

Also note that an exception does not have to terminate an application as you have said. An exception can be handled by the programmer and corrected or turned into some meaningful error to the user.


*The use of checked exceptions (exceptions that are forced to be caught) is a bit of a sore spot. Some (perhaps most) developers find that forced exception handling is cumbersome, unneeded, and just bad practice.

share|improve this answer
2  
I disagree, this definition is too limited. Only a subset of exceptions should ever be displayed to the user. Exceptions are for error handling, and giving up and informing the user is the last step taken usually, and shouldn't be the norm. Some systems are designed to use exceptions for some kinds of flow control too, like end of iterable, EOF, etc. –  Jürgen Strobel Oct 14 '11 at 22:36
    
Jürgen, I understand and completely agree with your comment. "corrected or turned into some meaningful error" - Am I not conveying that thought with this statement? –  Glenn Nelson Oct 14 '11 at 23:23
    
Yes it's much better now. –  Jürgen Strobel Oct 15 '11 at 10:52
    
Arguably, exceptions should never be shown to users. (The conditions that caused them to be generated might need to be reported to users somehow, but not as exceptions.) But an exception is always better than the program just doing a DIAF or a surprise exit. (“Every time I try to sort my email by sender name, the email client exits silently!!” No matter how clean that exit is, it's still wrong.) –  Donal Fellows Oct 16 '11 at 18:13

Exceptions allow modern error handling by splitting the error location from the error handler. Sometimes this is used for flow control too.

Unhandled exceptions terminate a program. But these are not different from the former exceptions, just a lazy programmer who forgot to include proper error handlers in every path makes them visible to the end user. I consider a program terminated by exception as crashed same as any other unexpected end.

OSes are very good an cleaning up crashed processes no matter how they crashed, so exceptions don't add safety for the OS any other way than terminating malfunctioning processes and releasing their resources.

share|improve this answer

It's very simple.

  • To only crash the program and not the entire system - we have [good] Operating Systems.
  • To crash a program instead of ignoring a fatal error - we have exceptions.

Before exceptions were invented, every function had to return an exit code (error/success) and any result or output from the function had to be retrieved by passing it a pointer to memory to be set by it.

The problem was that many programmers did not remember/bother to check for erroneous exit codes for every single function, and hence fatal errors were sometimes ignored, leading to quite unexplainable behaviors.

Therefore, it was decided - when an error happens, which you did not take into consideration, crash immediately! AKA Exception Handling.

share|improve this answer

Exeptions exists to separate normal program flow (what the program is designed to do) from the error handling flow (how program is trying to recover from an exceptional situation).

This makes code more clear and easier to maintain.

Consider two code sniplets:

try:
    do1()  # this is obvoiusly a normal
    do2()  # program flow
except:
    oups()  # this is exception handling code

Compared to this one:

if foo():
    thing1()  # is this part of normal program flow?
else:
    thing2()  # or maybe this one? Or both? When?

Of course, exception handling can be used to prevent program from crashing by:

try {    // very bad code
    my();
    whole();
    ugly();
    application();
    here();
} catch (Throwable t) {
    // pretend it's ok
}

but this is not the reason for the exceptions in modern programming languages.

You can also use while and break instead of if but this is not what while and break are for.

share|improve this answer
    
Actually handling "abnormal" control flow is precisely when goto and its friend break are the most useful. The advantage of exceptions is that they can cross function boundaries and that the caller can determine where its most apropriate to catch it. –  hugomg Oct 16 '11 at 20:10

Exceptions are simply an error detection mechanism. By themselves they are of no use.

But by detecting an error, they allow to trigger fault tolerance mechanisms in order to recover from the erroneous state by switching to an error-free state (a previous state or a new one). That way, the error is not propagated to other parts of the system.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.