Jan 30, 2012 at 8:28 PM
Edited Jan 30, 2012 at 8:30 PM
No, I think it is good to have the IndexerException (and other subclasses, as needed). I didn't mean to suggest only using the SandoException... using subclasses of the SandoException to specify exactly what's going wrong seems better. Is that
what you think too or do you want to go with the single exception type?
I definitely want go with subclasses - thanks for feedback!
One comment on code contracts for all of you guys - it is better when you use methods like "Requires", not "Requires<>" (the second one is implemented for backward compatibility and allows you to throw custom exception type when contract failed). The
usage of the first one can be difficult, because ContractException class is not a public one - you cannot catch this exception. So if you would like to test the code (i.e. in unit test) with contract failing for some of the requirements, you should use ContractFailed
Contract.ContractFailed += (sender, e) =>
e.SetHandled(); //this line says that the exception is handled - execution continues normally
e.SetUnwind(); //this line prevents executing code after the contract checking
contractFailed = true; //this is a private bool variable (you can use different approach),
//a flag, which can be used for Asserts - example below
Example of unit test:
Analyzer analyzer = new SimpleAnalyzer();
DocumentIndexer target = new DocumentIndexer("C:/Windows/Temp", analyzer);
//catch is still needed, because unwinding inside the ContractFailed event causes the exception to be thrown.
//However, at this moment we have our flag set
Assert.True(contractFailed, "Contract should fail!"); //contract failed - the flag is set if contract fails
If you have any questions - feel free to ask. The code is copied from DocumentIndexerTest class