But why should we wrap the checked exception in RuntimeException?
converting checked exception into unchecked exception depends on business scenario.
Normally such conversion code should not occur .. exception should be clearly defined and categorized during design time of app.So always avoid this conversion at the first place.
But there are scenarios where in we require this conversion. For example -
consider an Stateless
EJB which refer to an external Web Service implementation through @WebServiceRef annotation. This external web service is accessed through well defined WSDL file. This web service defines SomeFaultException in WSDL for its operation. Now in EJB method, we call external Web Service method to execute some business logic. Now let us say that web service returned checked exception [ means SomeFaultException (defined in WSDL)] back to EJB code. In this situation, we have to 3 options to handle this situation in EJB code
Option1
Option 2
Option 3
In Option 1, we are silently suppressing SomeFaultException and just printing stack trace on console. In this case, further code shall continue to run without even knowing that web service call has failed.
In Option 2, we are NOT suppressing SomeFaultException and wrapping it in Runtime Exception so that execution can be halted and we are preserving original SomeFaultException details by passing this exception in Runtime exception constructor.
In Option 3, we are propagating SomeFaultException to the method which calls this EJB method. This practice is normally not good as we are propagating/exposing web service exception into other layers of application. Normally, in application, only exceptions related to that application should be thrown and propagated.
Which option a developer choose depends on Business scenario and requirements.
Hope this explanation help !!
happy learning