Re: [Springframework-developer] Exception handling within the framework

[Rod J. <rod...@in...>]

Fine by me.

Rod
----- Original Message ----- 
From: "jürgen höller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Thursday, November 13, 2003 12:07 PM
Subject: [Springframework-developer] Exception handling within the framework


I've committed subtle changes to quite a few files, in an effort to
generally refine our exception throwing and handling.

Most importantly, ApplicationContextException extends FatalBeanException now
(analogous to BeanDefinitionStoreException). This finally clarifies how to
propagate exceptions through bean lifecycle methods and bean post
processors. For example, ApplicationContext.getBean throws BeansException
but ApplicationContextAware's setApplicationContext method just threw
ApplicationContextException. It now throws BeansException which covers both.
Same for quite a few other points in the framework. My main goal was to make
it clear that an ApplicationContextException should not get wrapped in a
BeansException or vice versa, as the latter is just a specialization of the
former.

Furthermore, BeanFactoryAware.setBeanFactory just throws BeansException
instead of the former Exception, just like
ApplicationContextAware.setApplicationContext already did before. The main
rationale is consistency: Just
InitializingBean.afterPropertiesSet/"init-method" and
DisposableBean.destroy/"destroy-method" are allowed to throw any exception
(the configurable reflection-based callbacks absolutely have to), every
other callback encourages a certain kind of exception. Obviously, runtime
exceptions like IllegalArgumentException and IllegalStateException can
always be thrown.

The only additional try-catch block necessary was in
AbstractPoolingInvokerInterceptor. Its setBeanFactory implementation now
wraps exceptions from the underlying pooling tool in a
BeanInitializationException. I consider it cleaner to have it the way it is
now, for consistency within the framework. If there are strong objections,
we can of course change setBeanFactory back to throw Exception. But I guess
that BeanFactoryAware is hardly used in applications anyway; and if it is
used, then mainly just for retrieving collaborating beans.

Juergen


DI Jürgen Höller
Senior System Architect
______________________________________

werk3ATS - division systementwicklung
werk3AT informations- und mediensysteme

europaplatz 4
A - 4020 linz

t.  +43 (0) 732 71 65 29 502
f.  +43 (0) 732 71 65 29 3
mailto:jue...@we...
http://www.werk3at.com
______________________________________
werk3ATS - WIR ENTWICKELN ERFOLG


-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! http://www.apachecon.com/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer