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

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.

Quote:

---

Originally Posted by Chris Beams

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

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

---