-1


I am working on a ReST based service which calls other ReST based services and also deals with Persistence in a database. So a typical call might look like

  1. Get some data from the database.
  2. Make a call to an external service using a ReSTClient to create a record.
  3. Persist the response to the database.
  4. Make another call to another service.
  5. Return a response back.

The problem being that both the ReSTClient and the DB persistence layer throws only their own custom RuntimeExceptions. I don't want to pollute my code with try catch blocks around each step and so wanted to have a high level exception mapper that basically returned back a 500 error code to the caller with a basic message that the call failed. Some developers say we must put a try catch block around each step and catch the RuntimeExceptions and return back a 500 error code but also the exact reason for the failure. My experience has shown that exact error messages when shown to the user doesn't add much value since the user doesn't actually understand our system and doesn't really know what it means to have the service call fail vs a failure in the database layer, he just knows the operation has failed. Also there is no guarantee that the client calling our service is a human user, could be another service.
Also during development certain situations can happen like for eg. step 2 is successful but step 3 fails because of a database failure. In this case the system is in an inconsistent state where the successful call is not recorded in the DB and if the human user doesn't know this then he make execute the operation again to create two records in the external system. There would be many such cases with regards to DB and disk failures etc. that we can't predict. So do you catch these exceptions at each step and write code and error messages to handle these situations.

Improve this question
3
  • 1
    please don't cross-post: stackoverflow.com/questions/45538742/… "Cross-posting is frowned upon as it leads to fragmented answers splattered all over the network..." Commented Aug 7, 2017 at 17:22
  • 2
    It sounds like you have a pretty good handle on this. What is your specific question? Commented Aug 7, 2017 at 17:31
  • I would at least make sure the HTTP 500 error is only returned for real server errors, not situations that can be corrected by the client . Commented Aug 8, 2017 at 21:07

1 Answer 1

Reset to default
0

I would mainly go the way you described.

The only situation where I'd go for local try/catch were if I had to do some rollback action - if ever possible.

To the user a 500 error code is perfect (that's what the standard defines, so let's not change that), and I agree that specific error messages don't make sense (sometimes when surfing the web I see failure traces on error pages, but even to me as an IT professional, they are useless).

Have a decent monitoring that informs some administrator who can take action in case of problems, and a good logging that provides the information to trace back the problem to its roots (including stack trace, relevant Request parameters etc.).

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.