Does exception handling require object-oriented programming?

Question

At this point in my programming experience, I realize how spoiled I am to have exception handling available in most languages being used today (C++, .Net, Java, etc), at least in comparison to C. I am getting ready to take an advanced C course and has me really thinking those terms in comparison to my current paradigm.

In C, it's up to the programmer to prevent errors from ever occuring in the first place, which is quite daunting for anybody who is used to exception handling. It has occured to me that any language that I have come across that has exception handling happens to be object oriented. The first object oriented language to have exception handling, at least to my knowledge, is C++ which is sort of an evolution of C. (please correct me if I am wrong)

With that said, is there something about the object oriented nature of a language that allows exception handling, or was exception handling added as a feature as object oriented languages really started becoming a commonplace? What is that C lacks that to say, C++, in machine code that makes excpetion work?

I found this post about how exception handling works under the hood, but not sure how that information applies to my question (ie, does C lack notifications, continuations, etc?). Thanks in advance.

Answer 1

C lacks nothing in machine code, and exception handling was and is commonplace in C with setjmp and longjmp.

The reason for the complete lack of a language-level feature in purely procedural languages is that exception handling is identical to setjmp when no destructors need to be called. Exception handling has been around before in exotic languages, but never caught on because it was purely syntactic sugar. However, once destructors entered the scene and stack unwinding became necessary, language-level support became necessary and exception handling was widely implemented as part of the language.

Answer 2

Does exception handling require object-oriented programming?

No. The two are completely separate. One can have OO languages that do not have exception handling as a control flow primitive, and one can have exception handling in non-OO languages.

Object-oriented programming, as Wikipedia helpfully points out, is a style of programming that emphasizes the value of abstraction, encapsulation, messaging, modularity, polymorphism, and inheritance in order to achieve low-cost code re-use and effective management of complex software projects implemented by large teams.

You don't see "loops" or "if statements" or "goto" or "try-catch-finally-throw" on that list because control flow primitives have nothing whatsoever to do with abstraction, encapsulation, messaging, modularity, polymorphism or inheritance being used to achieve low cost code reuse or effective management of complex software projects by large teams.

What is that C lacks that to say, C++, in machine code that makes exceptions work?

It is certainly the case that modern hardware is designed with exception handling as a control flow primitive in mind. C was designed long before that modern hardware existed, which would make it somewhat more difficult to implement exception handling in C that runs efficiently on all the hardware that C runs on.

But that said, there's nothing stopping you or anyone else from designing a new version of C that has exception handling as a control flow primitive, but without all the other features of C++.

If you're interested in the subject of how to add exception handling to non-OO languages that support continuations, see my article on the subject that sketches out the idea:

http://blogs.msdn.com/b/ericlippert/archive/2010/10/22/continuation-passing-style-revisited-part-two-handwaving-about-control-flow.aspx