Announcement Announcement Module
Collapse

JavaConfig forum decommissioned in favor of Core Container

As described at

http://static.springsource.org/sprin...fig/README.TXT

key features of the Spring JavaConfig project have been migrated into the core Spring Framework as of version 3.0.

Please see the Spring 3.0 documentation on @Configuration and @Bean support:

http://static.springsource.org/sprin...tml#beans-java

For any questions related to @Configuration classes and @Bean methods in Spring 3.0, please post in the dedicated 'Core Container' forum at

http://forum.springsource.org/forumdisplay.php?f=26
See more
See less
Propagate or catch checked Exceptions in @Bean methods? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Propagate or catch checked Exceptions in @Bean methods?

    Hi

    Letīs say that I'm creating a jms queue like this:
    Code:
    import com.sun.messaging.Queue;
    
    @Bean
    public Queue batchOrderQueue() {
    	return new Queue("queueName");
    }
    Queue declares that it throws javax.jms.JMSException which is a checked exception.

    What is the correct way to handle that exception?
    • Should I catch it and re-throw a RuntimeException?
    • Should I declare that the batchOrderQueue method also throws the exception?

    I'm new to SpringConfig, thatīs why I'm asking how to handle the exception in this particular circumstance.

    Best regards,
    Mattias

  • #2
    Hi Mattias,

    It would be customary here to simply declare the method as follows:

    Code:
    @Bean
    public Queue batchOrderQueue() throws JMSException {
    	return new Queue("queueName");
    }
    The idea is that if a JMSException is thrown when creating the queue, something must be fundamentally wrong, and you want to 'fail fast'. The enclosing application context will propagate this exception, ultimately as a BeanCreationException that wraps the JMSException cause. The benefit, of course, is that you're not burdened with programmatically handling the exception in any way.

    The only time that you would consider catching the exception yourself within the @Bean method is if there is actually a legitimate recovery scenario that you want to account for.

    Comment


    • #3
      Originally posted by Chris Beams View Post
      The idea is that if a JMSException is thrown when creating the queue, something must be fundamentally wrong, and you want to 'fail fast'. The enclosing application context will propagate this exception, ultimately as a BeanCreationException that wraps the JMSException cause. The benefit, of course, is that you're not burdened with programmatically handling the exception in any way.

      The only time that you would consider catching the exception yourself within the @Bean method is if there is actually a legitimate recovery scenario that you want to account for.
      Thanks Chris!

      This is exactly why I asked. Thank you for the explanation. I will declare the method to throw the exception and let Spring deal with it

      Because it is just as you say, I want the program to fail fast if a Queue can't be created.

      Best regards,
      Mattias

      Comment


      • #4
        Hi again

        I have a follow up question

        This is not really a big problem, just a little anoying.

        In the example below, one can see that just because the configuration method throws IOException all methods calling that one also have to throw IOException and so on...
        I think this really clutterns up the code when a lot of metods depend on the first one. What do you guys think?

        Example:
        Code:
        @Bean
        public DataSource dataSource() throws IOException
        {
        	DriverManagerDataSource dataSource = new DriverManagerDataSource(url(), username(), password());
        	dataSource.setDriverClassName(driverClassName());
        	return dataSource;
        }
        
        protected String url() throws IOException {
        	return getConfiguredProperty("jdbc.url");
        }
        
        private String getConfiguredProperty(String aPropertyName) throws IOException {
        	return configuration().getString(aPropertyName);
        }
        
        // This method throws IOException because it accesses a configuration file.
        @Bean
        public PersistentConfiguration configuration() throws IOException {
        	ClassPathResource propertiesResource = ....
        	....
        
        	return configuration;
        }
        Would it perhaps be better, in this case, to get rid of the throws clause by re-throwing the IOException as a RuntimeException?

        The application would still fail fast right?

        Code:
        @Bean
        public PersistentConfiguration configuration() {
        	try {
        		ClassPathResource propertiesResource = ....
        		....
        
        		return configuration;
        	} catch (IOException e) {
        		throw new RuntimeException(e);
        	}
        }

        Comment

        Working...
        X