Many times you know that due to user input or other external factors, a line of code will sometimes generate a non-fatal exception in your application.  You may not want your mailbox filled with silly bug reports about users entering bad passwords, Etc.  Using a simple trick you can "hide" these expected exceptions from EurekaLog.

EurekaLog will not trigger if you handle an exception locally with a TRY/EXCEPT block.  Using such a block means you are expecting an exception in some code and will handle it yourself.  You can also choose to silently ignore an exception if it is both expected and non-fatal to your program.

Here are two examples.  In the first button click handler we will let EL handle the exception.  In the second click handler, we will completely ignore the exception:

-------------------%------------------------

PROCEDURE TForm1.btnELHandlesExceptionClick(Sender : TObject);
BEGIN
    // no TRY/EXCEPT block, so EurekaLog will catch it
    RAISE Exception.Create('Red Alert! Send this bug report to the programmer with EurekaLog!');
END;

PROCEDURE TForm1.btnLocallyHandledExceptionClick(Sender : TObject);
BEGIN
    TRY
        RAISE Exception.Create('Move along folks; There is nothing to see here.');
    EXCEPT
        ON E: Exception DO ; // Do nothing.  EL will ignore this exception, because we have already handled it with the "ON E:..."
        // We could also add code here to take action on the exception with an "ON E: Exception DO HandleThisException"
        // We could also re-raise a new exception in our HandleThisException function
    END;
END;

-------------------%------------------------

Note that both exceptions will be caught by your IDE debugger's exception handler, but only the first one will generate an EL bug report.  You can configure your IDE debugger to ignore certain exception types, but that is for another article :-)