Describe the Bug

I was in the process of writing documentation to explain what to do when the set IConstructorFinder is unable to find any constructors on a component type and noticed we have multiple potential reporting mechanisms for the issue:

• If using the DefaultConstructorFinder, that finder throws its own NoConstructorsFoundException using a default message: No accessible constructors were found for the type '{0}'.
• If using a custom IConstructorFinder, the ReflectionActivator throws the NoConstructorsFoundException but with a custom error message: No constructors on type '{0}' can be found with the constructor finder '{1}'.

This is not only inconsistent (the interface IConstructorFinder indicates you can/should return an empty set and let the activator deal with it) but it also makes it hard to document or prescribe troubleshooting for since the message is so different from one report to another.

I propose:

• Remove the exception throwing from DefaultConstructorFinder. Let the ReflectionActivator handle it.
• Update the NoConstructorsFoundException to have a constructor that takes two parameters - the type being scanned and the type of the constructor finder - and use the message from the ReflectionActivator as the message for that constructor.

That would make the message (and stack trace) consistent across the default and specified constructor finder and would make documenting the issue easier.