"Throw an error" makes no sense at the hardware level. That's like saying a NIC should "throw an error" when it loses link. It's up to languages and libraries to turn signals/registers/flags into higher-level concepts like structured exceptions.

The IEEE standard contains a signalling NaN which is intended to throw an error when it is attempted to be used. It is not the result of any calculation, however, so typically it's only used as a marker to indicate that code is improperly attempting to access uninitialized data. There are such things as hardware exceptions and hardware interrupts on exceptions; and these things will trigger on sNaN in a (compliant) hardware FPU implementation.

My contention is that all NaN-resulting operations (Inf * 0, sqrt(-), e.g.) should halt the program instead of propagating a silent, dud value. When you reach them, it means usually there is something wrong with your algorithm (or less commonly, your data) and it is better to know that sooner than later.