Having read a post yesterday, I realized I did not know much about the origin of exceptions. Is it an OOP related concept only? I tend to think it is, but again there are database exceptions.

  • I once read that a "Mr Goodenuf" (or similar) invented exceptions in response to "never mind, it's Goodenuf, eh!" style bullying. I can't seem to find a reference now - maybe someone else can. It would be interesting to know which language they were added to first.
    – user8709
    Jan 8, 2013 at 13:06
  • 7
    Haskell has exceptions and it's not OOP at all Jan 8, 2013 at 14:52
  • 1
    Although exceptions themselves are not strictly object-oriented, the common practice of defining exceptions as objects and throwing and catching instances of these objects clearly is very OOP.
    – Dougvj
    Jan 8, 2013 at 16:13
  • What is the difference between an exception and a GOTO would be an interesting question. Jan 8, 2013 at 22:46
  • 2
    @Austin - how about "although exception throws violate the single exit point principle that some of the strictest disciples of structured programming advocate as an absolute, they don't allow unconstrained spaghetti control flow in the way that goto does. In particular, the target of the throw is determined by context, based on the nesting of block structures. As such, exceptions are even dependent on a slightly less strict form of structured programming where the single exit principle is taken as a guideline, but not an absolute".
    – user8709
    Jan 9, 2013 at 20:37

8 Answers 8


Exceptions are not an OOP concept.

But they are not completely unrelated either in one little tiny point.

As other answers have shown: The concept of exceptions has made it in several non-OOP languages. Nothing in that concept requires something from OOP.

But any if not all OOP languages which takes OOP seriously require exceptions because the other methods of error-handling fail at one specific point: The constructor.

One of the points of OOP is that an object shall encapsulate and manage its internal state completely and consistently. This also means that in pure OOP you need a concept to create a new object with a conistent state "atomically" - everything from memory allocation (if required) to the initialisation to a meaningful state (i.e. simple zeroing the memory is not enough) must be done in one expression. Hence a constructor is required:

Foo myFoo = Foo("foo", "bar", 42);

But this means that the constructor can also fail due to some error. How to propagate the error information out from the constructor without exceptions?

  • Return value? Fails since in some languages new could return only null but not any meaningfull information. In other languages (e.g. C++) myFoo is not a pointer. You could not check it against null. Also you cannot ask myFoo about the error - it is not initialized and therefore "does not exist" in OOP thinking.

  • Global error flag? So much about encapsulating state and then some global variable? Go to h... ;-)

  • A mixture? In no way better.

  • ?

So exceptions are a more fundamental concept than OOP but OOP builds upon them in a natural way.

  • 3
    as far as I can tell, the only word in this "answer" that addresses the actual question asked is "not". The rest seems to be about exceptions in OOP - with all due respect to me this reads somewhere between vaguely related and totally irrelevant - again, in the context of the question asked
    – gnat
    Jan 9, 2013 at 0:53
  • @gnat: The TO also says he does not know about the origins of exceptions. Hence a little background why exceptions are everywhere in OO land seemed to be OK for me. YMMV
    – A.H.
    Jan 9, 2013 at 18:31
  • 1
    @A.H. I have to agree with gnat, aside from the opening line, it really doesn't address the question. Your response to gnat was "says he does not know about the origins of exceptions" yet you didn't actually give an origin of exceptions, just some random usage of exceptions during object instantiation.
    – user7007
    Jan 25, 2013 at 13:35
  • 1
    Guys, seriously? -1? Most of the other answers aren't 100% to the point, either. +1 from me to compensate. This answer gives good background advice in a world of broken class designs. (Amendment: Mention multi-step constructors should be avoided)
    – Jo So
    Sep 3, 2014 at 12:48

Is it OOP related only?

No. Exceptions and OOP are unrelated.

Exceptions handling is a mechanism to handle errors. An exception is handled by saving the current state of execution in a predefined place and switching the execution to a specific subroutine known as an exception handler.

Comparing C (not really OOP language, possible to somehow emulate exceptions in C) and C++ (OOP, supports exceptions), nothing prevents C's standard committee from adding exceptions handling to C, it will still not make C an OOP language.

  • 2
    You could even argue there are already some sort of exceptions supported in the usual OS. Let your program crash (the uncaught "exception") and with a core dump and a debugger, you even get a stack trace.
    – bhaak
    Jan 8, 2013 at 11:48
  • 12
    Even MS BASIC form the early 80's had exception handling: ON ERROR GOTO xxxx
    – jwernerny
    Jan 8, 2013 at 13:29
  • 1
    @bhaak He could also be talking about Memory dumps in Windows
    – JohnL
    Jan 8, 2013 at 14:01
  • 11
    @jwernerny Error handling? Sure. But nobody would call that exception handling. In fact, it was routinely contrasted to (structured) exception handling. Jan 8, 2013 at 15:29
  • 1
    @jwernerny not sure I follow; exception handling as I've understood it is a very specific way to do error handling. When I hear exception I always think of the try catch construct.
    – Andy
    Jan 8, 2013 at 22:33

An exception is, simply put, an exceptional situation requiring attention and often a change in the flow of a program's execution. By that definition, exceptions and exception handling are not limited to object orientation, and simple program errors can be considered a form of exception.

Object oriented languages typically have a native exception class, and depending on context the word "exception" might indeed refer to that native class instead of the general concept. Object oriented exception handling is, as most of object orientation, syntactic sugar, and can be easily emulated in decisively non object oriented languages. Here's a C example, from the C Programming wikibook:

#include <stdio.h>
#include <setjmp.h>

jmp_buf test1;

void tryjump()
    longjmp(test1, 3);

int main (void)
    if (setjmp(test1)==0) {
        printf ("setjmp() returned 0.");
    } else {
        printf ("setjmp returned from a longjmp function call.");
  • 6
    It is not merely syntactic sugar. Recreating a full stack unwinding and type-based catch handlers is difficult with setjmp. Additionally, the specialty compilation of exceptions results in advantages which cannot be mimiced by setjmp. Jan 8, 2013 at 12:01
  • 3
    I hate the description exceptions are exceptional situations. I would rather say exceptions should be generated (thrown) when an error situation can not be resolved with the current context because there is not enough information in the current context to correctly fix the error. Jan 8, 2013 at 17:31
  • +1 for setjmp.h
    – gnat
    Jan 8, 2013 at 22:45

The answer is a simple NO.

A good example for a non-OO language with exceptions is ADA.

  • 4
    Hm, why is ADA not an OO language? Granted, ADA83 lacked polymorphism but it could still be considered object based. Also since ADA95 the language is fully object oriented.
    – yannis
    Jan 8, 2013 at 9:14
  • As far as I know exception handling is older than ADA83 therefore ADA in itself is a non-OO with exception handling.
    – Uwe Plonus
    Jan 8, 2013 at 9:46
  • 2
    @YannisRizos: Ada83 has packages and generic packages but not objects. They were introduced with Ada95.
    – mouviciel
    Jan 8, 2013 at 10:44
  • 2
    @Yannis - Objects without polymorphism is like structured programming without nested blocks. Polymorphism is one of the defining traits of OOP. Even in Ada95, the types that support run-time binding are called "tagged types" rather than "classes", though of course that's just spelling. Ada 83 had variant records and various other types, but none of those types provide features that are specific to OOP. Ada 83 was modular and structured, but it was not object oriented.
    – user8709
    Jan 8, 2013 at 12:07
  • 3
    @Yannis - basically, some people in the Ada community (like some advocates of most languages) can't accept that a feature can be good, yet not implemented in their favourite language, and will make up all kinds of excuses for believing otherwise. Yet it's not even as if a good language needs to have all possible good language features (though it's easy to believe the Ada designers thought so). I'm not really a believer in the minimalist approach to language design, but maximalist languages aren't perfect either.
    – user8709
    Jan 8, 2013 at 12:15

Some very good answers here already. Other examples for non-OOP programming languages having exceptions:

  • Oracle PL/SQL

  • classic Visual Basic (V6 and below, "On Error Goto" is IMHO a form of exception handling)

(To be nitty: you find some OO elements in both of the languages, but the exception handling mechanics does not make use of them, I guess because the concept was introduced years before the OO elements were added to those languages).

  • At least the later QuickBASIC versions on DOS (which predated Visual Basic; QB 4.5 was 1988 according to Wikipedia, VB 1.0 1991) had error handling using the ON ERROR GOTO syntax. Even QuickBASIC had a few OO-similar concepts (I think QB 4.5 even supported classes of some kind) but you'd be hard pressed to call mostly-traditional BASIC a proper object-oriented language. [Wikipedia]
    – user
    Jan 8, 2013 at 20:38

The basic idea behind exceptions is to clean up program flow so that a programmer can follow the "normal" execution path more easily. Consider a simple case of opening a file in C. Immediately after attempting to open the file, the programmer needs to examine the response from the fopen() call and decide if the call succeeded. If the call did not succeed, then the programmer must respond appropriately. The next call in the "normal" execution path, perhaps a call to fread() or fwrite(), would appear after the error or failure conditions have been handled. That may be on the next screen.

With a language that provides exceptions, the equivalent fopen() call can be followed immediately by the fread() or fwrite(). There is no error handling that is hiding the "next step" of the "normal" execution path. The programmer can see more of the normal path on a single screen, and so can follow the execution more easily. The error handling is moved to another part of the program.

Exceptions themselves are not an OOP concept, but they are often implemented using OOP concepts which make them more convenient and powerful. For instance, exceptions may be defined with an inheritance hierarchy. Using our notional example of opening and reading or writing a file, each of those calls may generate a variety of exceptions - FileClosedException, DeviceFullException, NoSuchFileException, InsufficientFilePermissionsException, etc. Each of those may inherit from FileException, which may inherit from IOException, which may inherit from GenericException.

If the programmer is doing a quick and dirty implementation to test a concept, he might mostly ignore exception handling and just implement a single handler for GenericException. That handler will handle a GenericException and any exception which inherits from GenericException. If he wants to treat any file related exception the same way, he can write a handler for FileException. That will be called for FileExceptions and any exceptions that inherit from FileException. If he wants to write a program that will respond differently to a variety of error conditions, he can write a specific handler for each specific exception.


Others have rightly answered "No" with examples of languages. I thought I could extend by adding an example on how to add exceptions to a language without ever involving OOP.

I will do this in case of the DSKL (Declarative Sequential Kernel Language) of OZ, a language well suited for academia stuff like this. The DSKL (or DKL) can be seen here (random search result), the Statements and Values part. The exact definition is not important, other than this being a very simple language with no modifiable variables (they are declared and later bound), and no OOP built in.

OOP can not even be added as an linguistic abstraction to this kernel language. By adding unique names to the kernel language (NewName) and using local scoping, encapsulation can be achieved. Or by adding a mutable state to the kernel language (NewCell) and using local scoping proper OOP with encapsulation can be achieved. But it can not be achieved with the specified kernel language alone.

If we then add exceptions to the kernel language we will have a language with no OOP-support but have exceptions. Let me show how:

Defining an abstract machine with a stack and a storage, we can define what each statement in our language should do (the semantics of the statement). For instance skip in the stack should do nothing, A = 3 in the stack should bind(/unify) A to(/with) 3.

We start by adding the syntax of how our exceptions should be defined. We do this by adding another two clauses to the <statement> in the DKL.

<statement>  ::== ... (old stuff)
                 | try <statement> catch <id> then <statement> end
                 | raise <id> end

Here is the known try/catch, and a way to raise/throw exceptions.

We define their semantics by how they should work on the abstract machine:

The semantic statement is: (try <statement1> catch <id> then <statement2> end)

  1. Push onto the stack the semantic statement (catch <id> then <statement2> end)
  2. Push onto the stack the semantic statement (<statement1>)

Note that statement 1 will be on top of the stack, and tried executed first.

The semantic statement is: (raise <id> end)

  1. If nothing more is on the stack, stop and report an uncaught exception.
  2. Else, pop the first semantic statement from the stack. If it's not a catch statement, go to step 1.
  3. We've gotten a catch, on the form (catch <id> then <statement> end)
    Push (<statement>) onto the stack.

If we see a catch-statement during normal execution, this means that whatever was inside executed without raising exceptions up to this level. Thus we just pop the catch of the stack and do nothing.

QED, we have a language with exceptions and no possibility of OOP.

I've removed the environment part from the abstract machine to make it simpler.



IIRC, exceptions appeared before the first OO languages. AFAIK, exceptions were first supported by early LISP implementations. Early structured languages (e.g. ALGOL) and early OO languages (e.g. SIMULA) did not support exceptions.

  • ALGON 68, of course, had exceptions ("events"), but it had everything else too. PL/I had them ("ON conditions") too, and there is literature from 1969 describing their use. Jan 31, 2013 at 3:36

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.