I understand your problem, but personally I don't think it's that useful having an option to change the default behaviour of F9.
You have some test cases which are expected to raise exceptions. (NOTE: I'm actually thinking tests that check for particular exceptions when bad inputs are given. Not exceptions being 'handled' by application.) And I agree there is no point in being alerted to these in most circumstances. However, an exception in other test cases would be a problem that I'd like to be alerted to as quickly as possible.
So my preferred running mode is to usually be notified of exceptions. And have explicit code in certain test cases that explicitly disables exception notification only within the context of the tests that will trigger production code exceptions.
I have a technique that works very well for this.
In a test that's expected to raise exceptions I write the following code:
begin
TIDEDebugTools.DisableBreakOnExceptions;
try
//Test code ...
finally
TIDEDebugTools.EnableBreakOnExceptions;
end;
end;
I guess you want the source code for those 2 methods? :)
unit IDEDebugTools;
interface
type
TIDEDebugTools = class(TObject)
public
class procedure DisableBreakOnExceptions;
class procedure EnableBreakOnExceptions;
end;
implementation
{ TIDEDebugTools }
class procedure TIDEDebugTools.DisableBreakOnExceptions;
begin
end;
class procedure TIDEDebugTools.EnableBreakOnExceptions;
begin
end;
end.
Where's the rest you ask?
There isn't any - that's it!
... but there are a few instructions you need to follow:
- Add a breakpoint to each of the method.
- Edit the breakpoint-properties.
- Select advanced options.
- Turn off the "Break" option
- And turn on the "Ignore subsequent exceptions" and "Handle subsequent exceptions" options for the appropriate respective method.
This is close to jpfollenius' idea for compiler directive options. It also addresses David's concern about how you enable those exceptions again. All you need to do is disable the breakpoints to get all exceptions reported again.
Additional thoughts:
You mention:
Some test code generates exceptions which are handled by the application.
If your application is handling all these exceptions, then:
- Are your tests localised enough? If you're testing such large chunks of functionality, the tests are more like system tests - and can be very difficult to maintain.
- Are you making too much use of exceptions for main-line business processing?
- Is your application doing a whole lot of inappropriate exception swallowing?
Basically it seems fishy to me that your wording suggested "a bunch of exceptions you're not too concerned about because they're 'handled'". Many people make the mistake of thinking they're handling a exceptions when really they're just swallowing them and hiding the root problems.
{$DoNotBreakOn EArgumentException}– jpfollenius