“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.