I am trying to understand the relationship between Interrupts / Exceptions in OS and programming languages. Please note that this is based on my understanding and I could be totally incorrect.
- Interrupts are generally initiated by hardware. Software Interrupts are also there - I have a question which I mentioned below.
- Exceptions are categorized into 3 types - trap, fault and abort
I am from Java background and I am trying to wrap my head around these concepts when I think of Exceptions in Java (or in any programming language).
I am particularly interested to understand the relationship between handlers provided by the programming language (need not be restricted to Java) vs the handlers provided by kernel to handle interrupts amd exceptions.
Are there any examples from JDK for trap, fault, abort categories? I know those are OS concepts, but I am tempted to think that at least a subset of the programming language exceptions might fall under these category.
What is the difference between software interrupt and trap (which is an Exception)?
Are there any examples from Java for a trap? I think the ones which results in a System call (like opening a file) can be a software interrupt trap.
I know it is a mouthful, thank you for your time.
CodePudding user response：
You're confusing hardware exceptions, which are categorized into 3 types (trap, fault, and abort) and software exceptions, which typically are not.
The distinction between trap, fault, and abort is the state of the machine after the exception, and affect whether continuation is possible, and whether such will re-execute the instruction that caused the exception, or the instruction after it.
A software exception typically begins with a call to some routine with a name like signal, raise, or throw. The exception dispatcher then searches for a handler, using whatever rules the designer found appropriate.
(Note that a hardware exception may be turned into a software exception - e.g. the hardware traps to a known address, and then the handler for that effectively 'raises' a software exception).
Software exceptions may be continuable, or not, based on the design of the mechanism. Java exceptions are not continuable; the stack is unwound before the exception handler ('catch' statement) is entered. So, if you really want to map Java exceptions to the trap/fault/abort classification, the closest match is 'abort'.
Other languages have different ideas - the handler may be entered before the stack is unwound, and the handler can unwind the stack, or else continue from the point of the exception, possibly after fixing a problem. These days, however, that approach ('resumption semantics') has fallen out of favour in favour of non-continuable exceptions ('termination semantics').
Summary: a software system or programming language defines its concept of exceptions. Hardware has similar but not identical concerns, but it is necessary for the OS or runtime system to map the hardware actions into a software exception. It might be the case, for example, that the hardware trapped into kernel mode, but the software exception needs to be delivered to a particular program in user mode.
It is not always the case that software exceptions are just implemented in the programming language. For example, Windows (and earlier systems, such as VMS) provides structured exception handling as a system-level function; language features may build on top of that, but the basic idea is available to all programs, including those written in assembly code.