“If you want to put everything under test, you have to write code like this.”
At least, that’s what Alex’s co-worker said to him, when Alex demanded an explanation for this block of code.
public interface ITrier
{
void Try<TException>(
Action tryAction,
Func<TException, bool> catchFunc)
where TException : Exception;
void Try<TException>(
Action tryAction,
Func<TException, bool> catchFunc,
Action finallyAction)
where TException : Exception;
TReturn Try<TReturn, TException>(
Func<TReturn> tryFunc,
Func<TException, bool> catchFunc)
where TException : Exception;
TReturn Try<TReturn, TException>(
Func<TReturn> tryFunc,
Func<TException, bool> catchFunc,
Action finallyAction)
where TException : Exception;
TReturn Try<TReturn, TException>(
Func<TReturn> tryFunc,
Func<TException, bool> catchFunc,
Action finallyAction,
Func<TReturn> defaultReturnFunc)
where TException : Exception;
TReturn Try<TReturn, TException>(
Func<TReturn> tryFunc,
Func<TException, bool> catchFunc,
Func<TReturn> defaultReturnFunc)
where TException : Exception;
}
Now, this code doesn’t precisely do anything, but don’t worry- Alex’s co-worker built an AbstractTrier class, which implements this interface, and can be inherited from in any situation where your testing patterns prohibit the use of try/catch blocks. There’s also a MockTrier, making this useful for testing, somehow.
And before you point out that there’s a perfectly good language construct that could be used instead of this interface or its implementors, Alex warns us that the “genius” behind this code also has crafted ILooper, and IConditional.