Types of Exceptions

The terminology used to describe exceptional situations where the normal execution order of instruction is changed varies among machines. The term interrupt, fault, and exception are used. We use the term exception to cover all these mechanisms, including the following:

I/O device request
Invoking an operating system service from a user program (system call)
Tracing instruction execution
Breakpoint (programmer-requested interrupt)
Integer arithmetic overflow or underflow; FP arithmetic anomaly
Page fault
Misaligned memory accesses (if alignment is required)
Memory protection violation
Using an undefined instruction
Hardware malfunction
Power failure

The requirements on exceptions can be characterized by five types:

Synchronous versus asynchronous.
If the event occurs at the same place every time the program is executed with the same data and memory allocation, the event is synchronous.
With the exception of hardware malfunctions, asynchronous events are caused by devices external to the processor and memory.
Asynchronous events usually can be handled after the completion of the current instruction, which makes them easier to handle.
User requested versus coerced
If the user task directly asks for it, it is a user-requested event. In some sense, user-requested exceptions are not really exceptions, since they are predictable. They are treated as exceptions, because the same mechanisms that are used to save and restore the state are used for these user-requested events.
Because the only function of an instruction that triggers this exception is to cause the exception, user-requested exceptions can always be handled after the instruction has completed.
Coerced exceptions are caused by some hardware event that is not under the control of the user program. Coerced exceptions are harder to implement because they are not predictable.
User maskable versus user nonmaskable
If an event can be masked or disabled by a user task, it is user maskable. This mask simply controls whether the hardware responds to the exception or not.
Within versus between instructions
This classification depends on whether the event prevents instruction completion by occurring in the middle (within) of execution or whether it is recognized between instructions.
Exceptions that occur within instructions are always synchronous, since the instruction triggers the exception.
It is harder to implement exceptions that occur within instructions than between instructions, since the instruction must be stopped and restarted.
Resume versus terminate
If the program's execution always stops after the interrupt, it is a terminating event.
If the program's execution continues after the interrupt, it is a resuming event.
It is easier to implement exceptions that terminate execution, since the machine need not be able to restart execution of the same program after handling the exception.

The following table describes different types of exceptions using the categories above:
Exception type	Synchronous vs. asynchronous	User request vs. coerced	User maskable vs. nonmaskable	Within vs. between instructions	Resume vs. terminate
I/O device request	Asynchronous	Coerced	Nonmaskable	Between	Resume
Invoke operating system	Synchronous	User request	Nonmaskable	Between	Resume
Tracing instruction execution	Synchronous	User request	User maskable	Between	Resume
Breakpoint	Synchronous	User request	User maskable	Between	Resume
Integer arithmetic overflow	Synchronous	Coerced	User maskable	Within	Resume
Floating-point arithmetic overflow or underflow	Synchronous	Coerced	User maskable	Within	Resume
Page fault	Synchronous	Coerced	Nonmaskable	Within	Resume
Misaligned memory accesses	Synchronous	Coerced	User maskable	Within	Resume
Memory protection violation	Synchronous	Coerced	Nonmaskable	Within	Resume
Using undefined instruction	Synchronous	Coerced	Nonmaskable	Within	Terminate
Hardware malfunction	Asynchronous	Coerced	Nonmaskable	Within	Terminate
Power failure	Asynchronous	Coerced	Nonmaskable	Within	Terminate

Synchronous, coerced exceptions occurring within instructions that can be resumed are the most difficult to implement.

The difficult task is implementing interrupts occurring within instructions where the instruction must be resumed because it requires another program to be invoked to
- save the state of the executing program;
- correct the cause of the exception;
- restore the state of the program before the instruction that caused the exception;
- start the program from the instruction that caused the exception.

If a pipeline provides the ability for the machine to handle the exception, save the state, and restart without affecting the execution of the program, the pipeline or machine is said to be restartable.

Almost all machines today are restartable, at least for integer pipelines, because it is needed to implement virtual memory.