API call return type and error handling I wrote the following method which would just call an API which would then update a user's subscription to something.
void updateSubscription(String userId, boolean subscribed){

        try{
            // some stuff
            restTemplate.exchange(.....)
           // some stuff
        }catch (HttpClientErrorException exception){
            log.error(&quot;API EXCEPTION - Received Status: {} - Stack Trace:&quot;,exception.getStatusCode(), exception);
            throw new ExternalAPIException(&quot;Service unavailable&quot;, HttpStatus.SERVICE_UNAVAILABLE);
        }catch (Exception e){
            log.error(&quot;API EXCEPTION - Stack Trace:&quot;, e);
            throw new ExternalAPIException(&quot;Internal Server Error&quot;, HttpStatus.INTERNAL_SERVER_ERROR);
        }
    }

I have two questions in particular:

Is the void return type okay? I am actually leaning towards returning a boolean indicating if the request was successful.
Is the error handling okay?

Note - it is a service class without a controller, so I can't use @controller's advice.
&quot;okay&quot; in programming often depends on context.
You chose to perform error handling by throwing exceptions, so there is no point in having a boolean return value - there will be no case where false is returned.
If you are asking whether it is better to return false rather than throw exception, that largely depends on the situation.
Your current error handling is already more granular than just success / failure - you want to detect different types of errors and respond differently, so the exception method is more appropriate.
Note that if you were to switch to return and maintain same granularity, you would need to use an Enum of possible results.
As for &quot;Is error handling ok&quot; - again, that depends.
How much 'some stuff' do you have around the API call?
What kind of stuff is it?
You may want to limit the amount of code in the catch block, and have separate catch blocks for other parts of code that may fail independently of any server errors.
Then again, how granular do you want to make your error handling?
Usually, the more precise the error and the more information user of the function has regarding why it failed the better, but if there are some constraints or type of errors that are not important they may be omitted, consolidated, or handled silently.