5

From an OS book, I learned that exceptions (such as arithmetic overflow, undefined instructions, invalid memory access) will cause cpu to switch from user mode to kernel mode, so that the OS can handle the exceptions

In high level programming languages, we can catch and handle default (as those mentioned above) or self-defined exceptions in programs, e.g. in C++, by using try and catch, and similar constructs in Java and in Python. I notice that exception handlers are given in user programs in such cases.

With such explicitly catching and handling exceptions in a user program,

  • will default exceptions still cause cpu to switch from user mode to kernel mode, so that the OS can handle the exceptions?

  • will self-defined exceptions still cause cpu to switch from user mode to kernel mode, so that the OS can handle the exceptions?

Thanks! (If OS-specificness is needed, then Linux)

Tim
  • 1
  • 141
  • 372
  • 590
  • 1
    Not really the same type of "exception"... – Macmade Feb 07 '15 at 17:25
  • @Macmade; what do you mean? thanks. – Tim Feb 07 '15 at 17:38
  • 1
    Tim, the hardware exceptions are always handled by the kernel, as controlled by the exception vector (which is basically an array of function pointers). The kernel then generates a signal to the user code (on Linux it's actually called a "signal", on Windows it's SEH), and generally your language's runtime library receives that signal and converts it to what the language calls an exception, and is what the programmer can also throw at will. But the hardware exception wasn't a language exception originally, and it's even possible that it never becomes one. – Ben Voigt Feb 07 '15 at 17:42
  • For example, in C++ code on Linux, hardware exceptions are handled by installing a signal handler, because the runtime library doesn't provide one by default. (The kernel exception handler still gets involved to raise the signal, of course) – Ben Voigt Feb 07 '15 at 17:42
  • @BenVoigt: Thanks. In a computer architecture book, it says arithmetic overflow, undefined instructions, and invalid memory access will cause switch to kernel mode. They sound like software exceptions to me, so are they hardware exceptions? (What books can I find out the differences between language exceptions and non-language exceptions?) – Tim Feb 07 '15 at 18:25
  • 1
    Those are detected by CPU hardware circuits. Sure, software could detect some of them, for example divide by zero, but that would be adding a conditional branch before every division instruction. Assuming that division by zero happens only rarely, the average cost of the hardware exception is lower than the guaranteed cost of the software test. And detecting the non-arithmetic traps in software would be ridiculously expensive. Feel like iterating through the page table prior to every pointer access? – Ben Voigt Feb 07 '15 at 20:00

2 Answers2

2

At the risk of oversimplification, the operating system usually allows a process to define an exception handler (signal handler in Unix). The hardware exception goes to kernel mode. The kernel mode handler then looks for the user model handler and invokes that.

The language runtime sets up the operating system specific exception handler so that it will invoke the language defined exception handler.

Matt
  • 17,290
  • 7
  • 57
  • 71
user3344003
  • 20,574
  • 3
  • 26
  • 62
1

Java virtual machine specification says that when an exception is thrown, it looks for a proper exception handler:

Each method in the Java Virtual Machine may be associated with zero or more exception handlers. An exception handler specifies the range of offsets into the Java Virtual Machine code implementing the method for which the exception handler is active, describes the type of exception that the exception handler is able to handle, and specifies the location of the code that is to handle that exception. An exception matches an exception handler if the offset of the instruction that caused the exception is in the range of offsets of the exception handler and the exception type is the same class as or a subclass of the class of exception that the exception handler handles. When an exception is thrown, the Java Virtual Machine searches for a matching exception handler in the current method. If a matching exception handler is found, the system branches to the exception handling code specified by the matched handler.

And if such an exception handler is not found - it will complete abruptly:

A method invocation completes abruptly if execution of a Java Virtual Machine instruction within the method causes the Java Virtual Machine to throw an exception (§2.10), and that exception is not handled within the method. Execution of an athrow instruction (§athrow) also causes an exception to be explicitly thrown and, if the exception is not caught by the current method, results in abrupt method invocation completion. A method invocation that completes abruptly never returns a value to its invoker.

And as to your question, when it completes abruptly - the control is passed back to the kernel.

Nir Alfasi
  • 53,191
  • 11
  • 86
  • 129
  • The only thing guaranteed is that control is passed to the nearest finally block or matching catch block. Whether the runtime enlists the kernel's help in finding those is implementation-specific. – Ben Voigt Feb 07 '15 at 17:39