Whose responsibility is it to throw an exception?; OS or process?

Question

How do exceptions work from an Operating System's perspective?

Coming from C++, I can understand exceptions from a programmer's perspective.
When an exception gets thrown, the stack begins to unwind, and each activation record has the opportunity to catch and handle the exception.

But whose responsibility was it to throw the exception in the first place?

1. Is it the Operating System that sends a trigger to the process telling it to enter it's "exception handling state?"
2. Is the process invoking and handling exceptions in it's own program space, unpronounced to the OS?

Here are two crashing programs that illustrate my uncertainty.

int main(){

    int i = 1/0; //did the OS tell the process to end?

    return 0;
}

---

#include <exception>

int main(){

    throw 11;  //did the process tell the OS it needs to end?

    return 0;
}

Answer 1

You're talking about two completely different exception processes.

The first is provided by the OS. In Windows you can use __try and __except to handle them.

The second is provided by the C++ compiler and doesn't involve the OS in any way.

Answer 2

C++ exceptions are part of the language, defined by the language standard, and implemented by the compiler and runtime library. There are other exceptions that are detected by the CPU, like divide by zero or dereferencing a NULL pointer, both are examples of Undefined Behavior in the language standard. Those are faults in processor terminology and on x86 for example trigger a fault handler which is then serviced by the OS. The OS can then choose to report that fault to the process that caused it, on Unix this is done with signals. If your process has installed a signal handler for SIGSEGV for example, it can handle the fault generated by the CPU when the process dereferences a NULL pointer... that mechanism is separate from the C++ exceptions defined by the language.

In your example, when a C++ program throws an exception this is entirely handled by the compiler generated code and the language runtime library, there is no kernel call necessary and there is no hardware fault generated by the processor.

Answer 3

Since I'm only aware of one or two OS's written in C++, and the one I know better, doesn't officially use exceptions at all, that pretty much rules out exceptions being thrown by the OS.

The three main OS's (Linux, Windows, MacOS X), along with all forms of Unix (AIX, Solaris, HP-UX, etc) are written in C, along with almost any other commercially available OS that isn't written in assembler, so can not throw C++ type exceptions [that's not saying there aren't software driven exceptions, just that they are not the type of excepion you catch with a "try/catch" in C++ without some sort of translation].

In the first example, the OS is definitely involved [in all OS's that I know how they work], since division by zero causes a hardware exception on all machines that have division as a function, and thus the OS will need to be involved. Also, this will compile and fail in the same manner whether it is C++, C or you write the same thing in assembler. For most Operating Systems, they'll send a signal to the program, but since you have no code for handling signals, your code will most likely simply abort, telling the OS that something weird happened and it's giving up, not even bothering to unwind the stack.

In the second case, the OS is not at all involved. There is a "try-catch" block around the call to main, which says "Oops, someone threw something that wasn't caught, lets exit". The only part of that that involves the OS is the "exit this process", which of course will need to be done by the OS, although I do believe in most OS's, just returning from the 'start address of the application' will also have the same effect.