Handling response from another microservice
up vote
0
down vote
favorite
I have this piece of code placed in ESI class. There is switch
statement nested in a try-catch
block and it feels simply wrong for me (I have a suspicion that I'm close to exception driven development). I'm looking forward to read your suggestions on how could I potentially improve this code.
@PostConstruct
public void initialize() {
this.webTarget = this.client.target("http://demo1173642.mockable.io/");
}
public Message getMockMessage() {
Response response = null;
try {
response = this.webTarget.request().get();
switch (response.getStatusInfo().getFamily()) {
case SUCCESSFUL:
return response.readEntity(Message.class);
case SERVER_ERROR:
throw new WebApplicationException(ErrorCode.EXTERNAL_SERVICE_BAD_GATEWAY.getMessage(),
Response.Status.BAD_GATEWAY);
default:
throw new InternalServerErrorException(ErrorCode.EXTERNAL_SERVICE_EXCEPTION.getMessage());
}
} catch (Exception ex) {
logger.log(Level.WARNING, ErrorCode.UNEXPECTED_EXECPTION.getMessage(), ex);
if (response != null) {
response.close();
}
throw new InternalServerErrorException();
}
}
java
add a comment |
up vote
0
down vote
favorite
I have this piece of code placed in ESI class. There is switch
statement nested in a try-catch
block and it feels simply wrong for me (I have a suspicion that I'm close to exception driven development). I'm looking forward to read your suggestions on how could I potentially improve this code.
@PostConstruct
public void initialize() {
this.webTarget = this.client.target("http://demo1173642.mockable.io/");
}
public Message getMockMessage() {
Response response = null;
try {
response = this.webTarget.request().get();
switch (response.getStatusInfo().getFamily()) {
case SUCCESSFUL:
return response.readEntity(Message.class);
case SERVER_ERROR:
throw new WebApplicationException(ErrorCode.EXTERNAL_SERVICE_BAD_GATEWAY.getMessage(),
Response.Status.BAD_GATEWAY);
default:
throw new InternalServerErrorException(ErrorCode.EXTERNAL_SERVICE_EXCEPTION.getMessage());
}
} catch (Exception ex) {
logger.log(Level.WARNING, ErrorCode.UNEXPECTED_EXECPTION.getMessage(), ex);
if (response != null) {
response.close();
}
throw new InternalServerErrorException();
}
}
java
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
I have this piece of code placed in ESI class. There is switch
statement nested in a try-catch
block and it feels simply wrong for me (I have a suspicion that I'm close to exception driven development). I'm looking forward to read your suggestions on how could I potentially improve this code.
@PostConstruct
public void initialize() {
this.webTarget = this.client.target("http://demo1173642.mockable.io/");
}
public Message getMockMessage() {
Response response = null;
try {
response = this.webTarget.request().get();
switch (response.getStatusInfo().getFamily()) {
case SUCCESSFUL:
return response.readEntity(Message.class);
case SERVER_ERROR:
throw new WebApplicationException(ErrorCode.EXTERNAL_SERVICE_BAD_GATEWAY.getMessage(),
Response.Status.BAD_GATEWAY);
default:
throw new InternalServerErrorException(ErrorCode.EXTERNAL_SERVICE_EXCEPTION.getMessage());
}
} catch (Exception ex) {
logger.log(Level.WARNING, ErrorCode.UNEXPECTED_EXECPTION.getMessage(), ex);
if (response != null) {
response.close();
}
throw new InternalServerErrorException();
}
}
java
I have this piece of code placed in ESI class. There is switch
statement nested in a try-catch
block and it feels simply wrong for me (I have a suspicion that I'm close to exception driven development). I'm looking forward to read your suggestions on how could I potentially improve this code.
@PostConstruct
public void initialize() {
this.webTarget = this.client.target("http://demo1173642.mockable.io/");
}
public Message getMockMessage() {
Response response = null;
try {
response = this.webTarget.request().get();
switch (response.getStatusInfo().getFamily()) {
case SUCCESSFUL:
return response.readEntity(Message.class);
case SERVER_ERROR:
throw new WebApplicationException(ErrorCode.EXTERNAL_SERVICE_BAD_GATEWAY.getMessage(),
Response.Status.BAD_GATEWAY);
default:
throw new InternalServerErrorException(ErrorCode.EXTERNAL_SERVICE_EXCEPTION.getMessage());
}
} catch (Exception ex) {
logger.log(Level.WARNING, ErrorCode.UNEXPECTED_EXECPTION.getMessage(), ex);
if (response != null) {
response.close();
}
throw new InternalServerErrorException();
}
}
java
java
asked Aug 26 at 10:55
miki
567
567
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
up vote
0
down vote
In fact, your error handling is quite messed up: in the cases for server error and default you throw an exception, which you immediately replace with a different exception in your own catch block. I don't think that's what you meant to do. Furthermore, you only close() the response object in the exception case, but not in the success branch...
Nevertheless, the throwing of a WebApplicationException leads me to believing that we are in a RESTful application here. Thus, the best way would be to declare an excepton mapper to handle the underlying ProcessingException
(which is the only one your catch-all-block should encounter) and do not do the handling internally. For exception mappers, here's a tutorial to start with: https://dennis-xlc.gitbooks.io/restful-java-with-jax-rs-2-0-en/cn/part1/chapter7/exception_handling.html (but you will find a lot more resources using your favourite search engine.)
Having this out of the way, the only thing for your method to do is using a try-with-resources block for the response:
public Message getMockMessage() {
try(Response response = this.webTarget.request().get()) {
switch (response.getStatusInfo().getFamily()) {
case SUCCESSFUL:
return response.readEntity(Message.class);
case SERVER_ERROR:
throw new WebApplicationException(ErrorCode.EXTERNAL_SERVICE_BAD_GATEWAY.getMessage(),
Response.Status.BAD_GATEWAY);
default:
throw new InternalServerErrorException(ErrorCode.EXTERNAL_SERVICE_EXCEPTION.getMessage());
}
}
Thank you for your comprehensive response. Nevertheless, I'm afraid that you did not fully grasp the intention of the code. First of all -readEntity()
closes stream after successful read, so closing it once again by hand is not required Second thing - yes, I do replace the exception but first I log the exception from the another microservice for debugging purposes. Exception outside this microservice has code 502 which propagates inside my system with 500 code. This behaviour I'd like to keep.
– miki
Aug 27 at 7:37
Btw. read error messages represented byErrorCode
enum. Did you think that these are purposeless?
– miki
Aug 27 at 7:44
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
In fact, your error handling is quite messed up: in the cases for server error and default you throw an exception, which you immediately replace with a different exception in your own catch block. I don't think that's what you meant to do. Furthermore, you only close() the response object in the exception case, but not in the success branch...
Nevertheless, the throwing of a WebApplicationException leads me to believing that we are in a RESTful application here. Thus, the best way would be to declare an excepton mapper to handle the underlying ProcessingException
(which is the only one your catch-all-block should encounter) and do not do the handling internally. For exception mappers, here's a tutorial to start with: https://dennis-xlc.gitbooks.io/restful-java-with-jax-rs-2-0-en/cn/part1/chapter7/exception_handling.html (but you will find a lot more resources using your favourite search engine.)
Having this out of the way, the only thing for your method to do is using a try-with-resources block for the response:
public Message getMockMessage() {
try(Response response = this.webTarget.request().get()) {
switch (response.getStatusInfo().getFamily()) {
case SUCCESSFUL:
return response.readEntity(Message.class);
case SERVER_ERROR:
throw new WebApplicationException(ErrorCode.EXTERNAL_SERVICE_BAD_GATEWAY.getMessage(),
Response.Status.BAD_GATEWAY);
default:
throw new InternalServerErrorException(ErrorCode.EXTERNAL_SERVICE_EXCEPTION.getMessage());
}
}
Thank you for your comprehensive response. Nevertheless, I'm afraid that you did not fully grasp the intention of the code. First of all -readEntity()
closes stream after successful read, so closing it once again by hand is not required Second thing - yes, I do replace the exception but first I log the exception from the another microservice for debugging purposes. Exception outside this microservice has code 502 which propagates inside my system with 500 code. This behaviour I'd like to keep.
– miki
Aug 27 at 7:37
Btw. read error messages represented byErrorCode
enum. Did you think that these are purposeless?
– miki
Aug 27 at 7:44
add a comment |
up vote
0
down vote
In fact, your error handling is quite messed up: in the cases for server error and default you throw an exception, which you immediately replace with a different exception in your own catch block. I don't think that's what you meant to do. Furthermore, you only close() the response object in the exception case, but not in the success branch...
Nevertheless, the throwing of a WebApplicationException leads me to believing that we are in a RESTful application here. Thus, the best way would be to declare an excepton mapper to handle the underlying ProcessingException
(which is the only one your catch-all-block should encounter) and do not do the handling internally. For exception mappers, here's a tutorial to start with: https://dennis-xlc.gitbooks.io/restful-java-with-jax-rs-2-0-en/cn/part1/chapter7/exception_handling.html (but you will find a lot more resources using your favourite search engine.)
Having this out of the way, the only thing for your method to do is using a try-with-resources block for the response:
public Message getMockMessage() {
try(Response response = this.webTarget.request().get()) {
switch (response.getStatusInfo().getFamily()) {
case SUCCESSFUL:
return response.readEntity(Message.class);
case SERVER_ERROR:
throw new WebApplicationException(ErrorCode.EXTERNAL_SERVICE_BAD_GATEWAY.getMessage(),
Response.Status.BAD_GATEWAY);
default:
throw new InternalServerErrorException(ErrorCode.EXTERNAL_SERVICE_EXCEPTION.getMessage());
}
}
Thank you for your comprehensive response. Nevertheless, I'm afraid that you did not fully grasp the intention of the code. First of all -readEntity()
closes stream after successful read, so closing it once again by hand is not required Second thing - yes, I do replace the exception but first I log the exception from the another microservice for debugging purposes. Exception outside this microservice has code 502 which propagates inside my system with 500 code. This behaviour I'd like to keep.
– miki
Aug 27 at 7:37
Btw. read error messages represented byErrorCode
enum. Did you think that these are purposeless?
– miki
Aug 27 at 7:44
add a comment |
up vote
0
down vote
up vote
0
down vote
In fact, your error handling is quite messed up: in the cases for server error and default you throw an exception, which you immediately replace with a different exception in your own catch block. I don't think that's what you meant to do. Furthermore, you only close() the response object in the exception case, but not in the success branch...
Nevertheless, the throwing of a WebApplicationException leads me to believing that we are in a RESTful application here. Thus, the best way would be to declare an excepton mapper to handle the underlying ProcessingException
(which is the only one your catch-all-block should encounter) and do not do the handling internally. For exception mappers, here's a tutorial to start with: https://dennis-xlc.gitbooks.io/restful-java-with-jax-rs-2-0-en/cn/part1/chapter7/exception_handling.html (but you will find a lot more resources using your favourite search engine.)
Having this out of the way, the only thing for your method to do is using a try-with-resources block for the response:
public Message getMockMessage() {
try(Response response = this.webTarget.request().get()) {
switch (response.getStatusInfo().getFamily()) {
case SUCCESSFUL:
return response.readEntity(Message.class);
case SERVER_ERROR:
throw new WebApplicationException(ErrorCode.EXTERNAL_SERVICE_BAD_GATEWAY.getMessage(),
Response.Status.BAD_GATEWAY);
default:
throw new InternalServerErrorException(ErrorCode.EXTERNAL_SERVICE_EXCEPTION.getMessage());
}
}
In fact, your error handling is quite messed up: in the cases for server error and default you throw an exception, which you immediately replace with a different exception in your own catch block. I don't think that's what you meant to do. Furthermore, you only close() the response object in the exception case, but not in the success branch...
Nevertheless, the throwing of a WebApplicationException leads me to believing that we are in a RESTful application here. Thus, the best way would be to declare an excepton mapper to handle the underlying ProcessingException
(which is the only one your catch-all-block should encounter) and do not do the handling internally. For exception mappers, here's a tutorial to start with: https://dennis-xlc.gitbooks.io/restful-java-with-jax-rs-2-0-en/cn/part1/chapter7/exception_handling.html (but you will find a lot more resources using your favourite search engine.)
Having this out of the way, the only thing for your method to do is using a try-with-resources block for the response:
public Message getMockMessage() {
try(Response response = this.webTarget.request().get()) {
switch (response.getStatusInfo().getFamily()) {
case SUCCESSFUL:
return response.readEntity(Message.class);
case SERVER_ERROR:
throw new WebApplicationException(ErrorCode.EXTERNAL_SERVICE_BAD_GATEWAY.getMessage(),
Response.Status.BAD_GATEWAY);
default:
throw new InternalServerErrorException(ErrorCode.EXTERNAL_SERVICE_EXCEPTION.getMessage());
}
}
answered Aug 27 at 5:57
mtj
2,849213
2,849213
Thank you for your comprehensive response. Nevertheless, I'm afraid that you did not fully grasp the intention of the code. First of all -readEntity()
closes stream after successful read, so closing it once again by hand is not required Second thing - yes, I do replace the exception but first I log the exception from the another microservice for debugging purposes. Exception outside this microservice has code 502 which propagates inside my system with 500 code. This behaviour I'd like to keep.
– miki
Aug 27 at 7:37
Btw. read error messages represented byErrorCode
enum. Did you think that these are purposeless?
– miki
Aug 27 at 7:44
add a comment |
Thank you for your comprehensive response. Nevertheless, I'm afraid that you did not fully grasp the intention of the code. First of all -readEntity()
closes stream after successful read, so closing it once again by hand is not required Second thing - yes, I do replace the exception but first I log the exception from the another microservice for debugging purposes. Exception outside this microservice has code 502 which propagates inside my system with 500 code. This behaviour I'd like to keep.
– miki
Aug 27 at 7:37
Btw. read error messages represented byErrorCode
enum. Did you think that these are purposeless?
– miki
Aug 27 at 7:44
Thank you for your comprehensive response. Nevertheless, I'm afraid that you did not fully grasp the intention of the code. First of all -
readEntity()
closes stream after successful read, so closing it once again by hand is not required Second thing - yes, I do replace the exception but first I log the exception from the another microservice for debugging purposes. Exception outside this microservice has code 502 which propagates inside my system with 500 code. This behaviour I'd like to keep.– miki
Aug 27 at 7:37
Thank you for your comprehensive response. Nevertheless, I'm afraid that you did not fully grasp the intention of the code. First of all -
readEntity()
closes stream after successful read, so closing it once again by hand is not required Second thing - yes, I do replace the exception but first I log the exception from the another microservice for debugging purposes. Exception outside this microservice has code 502 which propagates inside my system with 500 code. This behaviour I'd like to keep.– miki
Aug 27 at 7:37
Btw. read error messages represented by
ErrorCode
enum. Did you think that these are purposeless?– miki
Aug 27 at 7:44
Btw. read error messages represented by
ErrorCode
enum. Did you think that these are purposeless?– miki
Aug 27 at 7:44
add a comment |
Thanks for contributing an answer to Code Review Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
Use MathJax to format equations. MathJax reference.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f202509%2fhandling-response-from-another-microservice%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown