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

Exceptions thrown by scoped proxy target factory methods are wrapped in a BeanCreationException, preventing easy access to root cause for handling purposes [SPR-8466] #13112

spring-projects-issues opened this issue Jun 17, 2011 · 2 comments
in: core status: declined type: enhancement


Copy link

@spring-projects-issues spring-projects-issues commented Jun 17, 2011

Keith Donald opened SPR-8466 and commented

In my case I have a scoped proxy target factory method that can throw a NotConnectedException. I need to handle this exception in a HandlerInterceptor. However, this exception gets wrapped in a BeanCreationException->BeanDefinitionStoreException, so I must detect it and introspect two nested root causes, which doesn't feel very clean conceptually. You can see this below:

 * A proxy to a request-scoped object representing the current user's primary Facebook account.
 * @throws NotConnectedException if the user is not connected to facebook.
@Scope(value="request", proxyMode=ScopedProxyMode.INTERFACES)	
public Facebook facebook() {
    return connectionRepository().getPrimaryConnection(Facebook.class).getApi();
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'scopedTarget.facebook' defined in class path resource [org/springframework/social/quickstart/config/SocialConfig.class]:
Instantiation of bean failed; nested exception is org.springframework.beans.factory.BeanDefinitionStoreException:
Factory method [public] threw exception;
nested exception is Not connected to provider 'facebook'

I would prefer to be able to work against NotConnectedException as the exception that was thrown.

Affects: 3.1 M2

Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jun 17, 2011

Chris Beams commented

Hi Keith,

Could NestedRuntimeException#getMostSpecificCause() work for your situation? It solves the problem of having to navigate explicitly through all causes yourself, but of course you're still dealing with a framework exception vs. the exception thrown natively.

I understand that this represents a bit of a leaky abstraction or at least an inconsistency - if the bean is a singleton no wrapping is performed, while if it's scoped as in your situation it does. Just wondering if the #getMostSpecificCause approach is 'good enough' for you.

package org.springframework.beans.factory;

import static org.hamcrest.CoreMatchers.instanceOf;
import static org.junit.Assert.assertThat;

import org.junit.Test;

public class Spr8466Tests {
	public void mostSpecificCause() {
		BeanCreationException ex =
			new BeanCreationException("bce",
				new BeanDefinitionStoreException("bdse",
					new MyException()));

		assertThat(ex.getMostSpecificCause(), instanceOf(MyException.class));

	class MyException extends RuntimeException {

Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jun 17, 2011

Keith Donald commented

Well, this is only a slight improvement over what I have now convenience wise, and ties me to NestedRuntimeException. I equate what is happening here to somewhat like a InvocationTargetException... and generally what we do in that case is propagate the cause instead of the invocation target wrapper.

@spring-projects-issues spring-projects-issues added status: declined type: enhancement in: core labels Jan 11, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
in: core status: declined type: enhancement
None yet

No branches or pull requests

2 participants