Let us change our traditional attitude to the construction of programs: Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do. (Donald Knuth)
Computers screw up. You can have meaningless instructions,
attempts to divide by zero, attempts to access non-existent memory,
and other situations the cpu can't deal with. These are all similar
events, and some are used interchangeably at times. There are
subtle differences in what these specifically mean, but there is
also a lot of overlap.
First, consider the mechanics: if we have a problem (like
division by zero or a bad memory reference), we need both code to
handle the problem and a way to get to that code. Handling might
mean printing an informative warning message, silently allocating
memory for a process that needs it,killing off an errant process,
or even shutting down the entire machine. The way to get to the
handler is going to be through some sort of vector table: if you
have problem number 0, jump to this code, and so on.
So all these things are really interrupts to normal CPU
instruction flow. If we want to be precise, we can say that
"interrupts" come from outside the cpu's hardware (some other
device requesting attention or program code requesting a software
interrupt), a "fault" happens before the CPU can execute the
instruction (divide by zero, bogus instruction), a trap happens
after or during the execution (a debugger breakpoint, an overflow
situation), and an "abort" is something where the CU has no idea
what is going on at all.