Results 1 to 4 of 4

Thread: Propagate or catch checked Exceptions in @Bean methods?

  1. #1

    Default 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. #2
    Join Date
    Apr 2007
    Posts
    307

    Default

    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.
    Chris Beams
    Spring Framework committer, VMware
    http://github.com/cbeams

  3. #3

    Default

    Quote 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

  4. #4

    Default

    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);
    	}
    }

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •