title: Masking floating point exceptions with Set8087CW, SetMXCSR and TWebBrowser
body: <p>As I am receiving "Floating point division by zero" exception when using TWebBrowser and TEmbeddedWB from time to time, I discovered that I need to mask division by zero exceptions Set8087CW or SetMXCSR.</p>
  
  <p>Q1: What would be the best approach to do this:</p>
  
  <ol>
  <li>to mask such exceptions early in the application startup and never touch them again (the app is multithreaded)?</li>
  <li>to use <code>OnBeforeNavigate</code> and <code>OnDocumentComplete</code> events to mask / unmask exceptions? (is there a chance that exception could occur after the document is loaded?)</li>
  </ol>
  
  <p>Q2: What would be the best "command" to mask only "division by zero" and nothing else - if application is 32-bit is there a need to mask 64 bit exception too?</p>
  
  <p>The application I am using it it has TWebBrowser control available all the time for displaying email contents.</p>
  
  <p>Also, if anyone can clarify - is this a particular bug with TWebBrowser control from Microsoft or just difference between Delphi/C++ Builder and Microsoft tools? What would happen if I would host TWebBrowser inside Visual C++ application if division by zero error would appear - it wouldn't be translated into exception but what would happen then - how would Visual C++ handle "division by zero" exception then?</p>
  
  <p>It is kind of strange that Microsoft didn't notice this problem for such a long time - also it is strange that Embarcardero never noticed it too. Because masking floating point exception effectively also masks your own program exception for that particular purpose.</p>
  
  <p><strong>UPDATE</strong></p>
  
  <p>My final solution after some examination is:</p>
  
  <pre><code>SetExceptionMask(GetExceptionMask() &lt;&lt; exZeroDivide);
  </code></pre>
  
  <p>The default state from <strong>GetExceptionMask()</strong> returns: <code>TFPUExceptionMask() &lt;&lt; exDenormalized &lt;&lt; exUnderflow &lt;&lt; exPrecision</code>. So obviously, some exceptions are already masked - this just adds <code>exZeroDivide</code> to the masked exceptions.</p>
  
  <p>As a result every division by zero now results with <strong>+INF</strong> in floating point instead of exception. I can live with that - for the production version of the code it will me masked to avoid errors and for the debug version it will be unmasked to detect floating point division by zero.</p>