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?

7 Answers 7


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."

  • 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, 2011 at 0:24
  • 1
    Couldn't I do the exact same thing with error codes? You return an error, and I handle it.
    – mskw
    Sep 17, 2016 at 4:46

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.


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.

  • 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. Oct 14, 2011 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?
    – user7007
    Oct 14, 2011 at 23:23
  • Yes it's much better now. Oct 15, 2011 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.) Oct 16, 2011 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.

  • There are limits to what an Operating System can clean up. In general, an OS cannot know whether any persistent resources (e.g. files) need to be cleaned up or rolled back, nor can it know if there's any cleanup needed for a remote connection, beyond simply closing the connection on the local side.
    – 8bittree
    May 20, 2019 at 18:39

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.


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.


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:

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

Compared to this one:

if foo():
    thing1()  # is this part of normal program flow?
    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
} 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.

  • 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, 2011 at 20:10
  • @hugomg: Another big advantage of exceptions is that they allow resource cleanup and other such actions to be performed between the place where an exception is thrown and the place it is handled.
    – supercat
    Apr 16, 2015 at 15:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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