You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
The text was updated successfully, but these errors were encountered:
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:DefaultConstructorFinder
, that finder throws its ownNoConstructorsFoundException
using a default message:No accessible constructors were found for the type '{0}'.
IConstructorFinder
, theReflectionActivator
throws theNoConstructorsFoundException
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:
DefaultConstructorFinder
. Let theReflectionActivator
handle it.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 theReflectionActivator
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.
The text was updated successfully, but these errors were encountered: