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

[spring-projects-issues]

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.
 */
@Bean
@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 org.springframework.social.facebook.api.Facebook org.springframework.social.quickstart.config.SocialConfig.facebook()] threw exception;
nested exception is org.springframework.social.connect.NotConnectedException: 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

[spring-projects-issues]

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 {
	@Test
	public void mostSpecificCause() {
		BeanCreationException ex =
			new BeanCreationException("bce",
				new BeanDefinitionStoreException("bdse",
					new MyException()));

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

	@SuppressWarnings("serial")
	class MyException extends RuntimeException {
	}
}

[spring-projects-issues]

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.