Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

distinguish "none found" from "several found" in NoSuchBeanDefinitionException [SPR-10194] #14827

Closed
spring-projects-issues opened this issue Jan 18, 2013 · 1 comment
Assignees
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

@spring-projects-issues spring-projects-issues commented Jan 18, 2013

Dan Lipofsky opened SPR-10194 and commented

ApplicationContext.getBean(Class) throws NoSuchBeanDefinitionException in 2 cases: when no beans are found and when more than one matching beans are found. The only way to tell the difference is by parsing the message (which is hardly reliable, the message could change). I would like a better way to programmatically tell the difference.

One way to do this would be to add a boolean flag (e.g. isNonUnique()) or an integer flag (e.g. getNumberOfBeansFound()) to the exception.

However, a better way might be a different exception, e.g. NoUniqueBeanException. This can be a subclass of NoSuchBeanDefinitionException for backwards compatibility.


Affects: 3.2 GA

Referenced from: commits 8f103c2, ece727b

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jan 22, 2013

Juergen Hoeller commented

Good point! I've introduced a NoUniqueBeanDefinitionException as a dedicated subclass of NoSuchBeanDefinitionException, with a new getNumberOfBeansFound accessor available on the base class (always returning 0) and overridden to return a number higher than 1 in NoUniqueBeanDefinitionException itself.

Juergen

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants