How should I handle checked and unchecked exceptions in Java Config @Bean method to display a user-friendly cause of the error? [duplicate]

Question

This question already has an answer here:

Graceful handling of exception thrown while creating beans (1 answer)

Closed 4 years ago.

I am developing a small spring-boot-based command-line application. The main class has an @Autowired-annotated field @Autowired Repository repository; whose construction recipe is provided in Java Config class that has an appropriate @Bean-annotated method @Bean Repository repository(){...}.

The @Bean-annotated method contains code that can throw checked and unchecked exceptions. @Bean Repository repository(){...//exceptions}

My target is to create a user-friendly application which logs brief messages at appropriate logging level rather than long stack traces.

Currently, an exception in Java Config @Bean-annotated method causes the application to exit with o.s.boot.SpringApplication: Application startup failed message and a very long stack trace.

I wonder if there is a good way to handle at least typical exceptions (which I am aware of) in Java Config @Bean-annotated method to log user-friendly brief messages useful for troubleshooting.

I assume such a strategy would expect adding exception handling code to Java Config class, but I have never seen such code in publicly available Java Config classes, which suggests exception handling code in Java Config classes could be a bad practice.

Thank you.

Answer 1

I think you have a few options here, and which one is the best is largely down to personal preference and the structure of your application.

One option would be to perform all of the input validation before you call SpringApplication.run(). This would work for any command line arguments, but would be cumbersome at best for anything configured via application.properties.

Rather than throwing exceptions from your @Bean methods, you could catch them and handle them appropriately. If the problem's minor you could log an info or warning message explaining the problem and allow the application to continue. If the problem's catastrophic, you could log an error message and then call System.exit(). While this will provide user-friendly error reporting for any exceptions thrown while your @Bean methods are being called, you'll still be left with stack traces for any exceptions that occur after that.

Lastly, you could wrap the call to SpringApplication.run() in a try-catch block. You could then examine the caught exception and the chain of causes to determine an appropriate error message to log. The advantage of this approach is that it will let you provide a user-friendly error message for any exception that causes SpringApplication.run() to fail, not just one that's thrown from within one of your @Bean methods.

Assuming there are command-line arguments to validate, I would probably use a combination of the first and third options. For the first I'd use a CLI library such as JOpt Simple to make things a bit easier.