Easy. Just test a combination of various homeopathic agents, with one of them actually being a real drug (under a fancy homeopathic name) at high enough concentration to have an actual effect.

I have seen studies done this way. Always check the homeopathic medicine in question for barely diluted, real drugs.

a) The program needs to process bursts incoming data quickly and timely, and it is known that only nonzero output values are valid. The program combs through received data later, when there is time.

b) You need to feed an audio DAC or something, and outputting 0 will result in a barely noticable glitch, but missing several samples due to exception handling will produce a very noticable acoustic artefact.

Or maybe you have bursts of data coming in that needs to be processed in a timely manner (leaving no time for exeptions or even checks), followed by periods in which you can comb through the data packets and deal with cases of division by zero (e.g. if you know that the result is normally nonzero, any zeros showing up in your data indicate that these samples need to be handled separately).

It's all a matter of your application.

If you have the CPU cycles for this, it is the better option. Depending on the application, you may not have this luxury (really low latency signal processing where trapping an exception will break the real-time behavior of the system).

Not ignoring the problem could be deadly, too, or at least very costly. It all depends on the application.

Why do you think ARM put a mode in their CPUs where they just return zero on a division by zero? Does ARM leave their CPU design to idiots? I don't think so.

Yes. Because other parts of the cruise control algorithm can recognize a speed of zero as a point where the cruise control should not be operating at all and disengage it.

The other options would be:

Report an arbitrary value. This leads to horrible results as the arbitrary value may be below the set speed, but still in a range where the cruise control operates.

Report the maximum value. This may lead to funny results if the programmer did not pay close attention to signed/unsigned datatypes.

Do random stuff, crash, require restart before cruise control can be re-engaged: This doesn't immediately lead to horrible results, but to lots of unhappy customers wondering why their car needs resets/power cycling like their Windows computer does.

ARM thinks that this is valid under certain circumstances and provides an appropriate setting in their CPUs (DIV_0_TRAP).

Would they do that if it was completely useless?

Statistically, returning zero usually yields less horrible consequences than returning an arbitrary non-zero number.

If the result of the division is used in further calculations, e.g. in a product, a zero won't cause additional undefined behavior by signed integer overflows, etc.

Depends on the code. If dividing by zero results in occasional audio glitches, it's not horribly broken. If dividing by zero results in the code occasionally killing people, it's horribly broken.

Depends on your CPU. It may have a setting to make it just return zero when dividing by zero. Sometimes, that's less harmful than other options.

It can be expanded to (0*1)/0 and then to 0*(1/0), since anything multiplied by one is itself.

Of course, you need to get down to assembly to mess with this setting, since most programming languages specify a behavior in this case, or behave in an unspecificed way.

Then again, dividing by zero usually means that there's something wrong with your design.

Please explain under which condition(s) the code

return GEngine ? GEngine->DisplayGamma : 2.2f;

will dereference a null pointer.

The construct is similar, but not identical. The difference is significant, though.