Hardware has classically detected abnormal situations that must normally abort the program unless application specific logic can sensibly react to the situation. Programming languages have almost completely failed to support such programs. Machines have sometimes omitted fixed point overflow indications for lack of ways to detect such by any language except assembler.
Here is how some of the Keykos kernels used page faults to efficiently access user memory with the user’s authority but so as to avoid exceeding the user’s authority. The kernel needs to copy some contiguous data from one user’s space to another user’s space. It would grab a few page table entries from each space and add them to its own space for the duration of the copy. The kernel’s access via these two windows into user space was thus just that of the respective user. The kernel would then use the normal instructions to move data. If one of the user’s authority was insufficient for the copy then the kernel would trap. The trap routine would note that the trapped code was the kernel by virtue of its privileged state. The trap routine would compare the trapped program counter with each member of a short list of addresses of kernel instructions that might cause such a trap. Upon match an alternate address, from a parallel table, was placed in the program counter and the kernel restarted, with other user registers unmodified. These tables were assembled and provided by the assembler programmer of the trapped program and thus provided explicit control of how to react to the exceptional situation. In the normal frequent case of no fault no extra overhead was needed by programmed tests to see of the users had the authority they claimed. This very small hack in the trap code effectively turned the memory accessing instructions into conditional transfers, a concept that compilers deal naturally with. (In the case of the 370 there was a bit of overhead tuning on the map which was otherwise off for the kernel.) When the kernel was so trapped it could explicitly give control to that software that normally responded to a memory trap by the user.
Most of the tests in this complex square root routine are to avoid floating point exponent overflow or underflow in intermmediate results. The hardware would have detected just the cases that the code detects but since there is no way to ask for such reports in C the expensive and redundant test are required. I suspect that new semantics are needed to solve this problem. PL/I has some such semantics but I forget the details.
This is the only compelling case that I have personally encountered for an exponent underflow causing an interrupt in contrast to silently producing a zero result. Indeed the square root routine would need to save and restore the old mode while asking for the report.