In principle I agree. But in this case, it isn’t your code that is throwing the exceptions; you are simply being forced into the position of catching them by someone else’s bad design. Refusing to call code that you know will throw an exception simply because you don’t consider the circumstance exceptional – when the only alternative is complex, difficult to maintain, and very unlikely to be 100% effective – doesn’t make much sense to me.

I was thinking more along the lines of an Interface definition or base class, versus the “typical” (lack of better word) constraints.

I am guessing that you already considered taking the “reflection hit” the first time the request is made to the specific TAI as opposed to loading them all at once?

I do the nasty reflection business at startup and then configure generic, properly-typed invokers and things to avoid the reflection hit every single request to every single action.

I’m looping over the types anyhow, no need to make the situation worse by adding a bunch of exceptions to the mix.

Exceptions are, by definition, exceptional. This is not an exceptional case. These are normal types that may or may not meet certain criteria I need.

Throwing and catching a lot of exceptions is just bad coding unless there is no other alternative.

I am curious as to why this is automatically unacceptable. Is it because of the potential performance problem? Because I am not sure that doing extensive reflection on the types is going to be any better. And I certainly wouldn’t go down the much more complicated way until I had at least tried the simple way to see if it feel within my requirements.

At least in this specific case, I’ve already checked to make sure that TInput is not an open generic type (i.e. Foo is ok, but Foo is not).

If we add another constraint to TInput (such as replacing ‘class’ with ‘struct’), this code I posted should handle it fine.

You or your team have to remember this method if you add another constraint on TInput.

Can TInput be generic? If TInput can be generic, will it ever be open when you attempt to create the invoker?

Yes, I do need it :) Catching exceptions is bad because I’ll be running this on potentially dozens or hundreds of types and that level of exception throwing/catching is unacceptable in my book.

The problem is I have an open generic type and I have candidate types to fill in the generic parameters. This is all via reflection, so I don’t have direct knowledge of the types, only their Type/reflection metadata.

I need to see if Type X will work as the “TInput” for “FooType where TInput : class, new()”

The only way I can see this in the BCL is to try calling MakeGenericType() and hope for the best. This is unacceptable, so I’m trying to evaluate the condition before blindly calling an exception-throwing method.

From what I can tell, based on the BCL, poking around in Reflector, and Google, you have to do the constraint checking yourself.