This question falls more into the theory side of things rather than a direct issue with some code I am writing.
What am I looking for?
I have a common problem which I am sure many people face daily and I would like to establish opinions and then answers. I am not sure if there is a correct answer or not but perhaps we'll get somewhere close.
The Problem.
I am creating a RESTful API. This API speaks to many different types of subsystem, DB's third party API's, SOAP etc...
In order for our code to be easy to read, maintain and test we are trying to come up with a consistent way of building our system. The problem we have is that for server errors and downstream errors we generate an exception which bubbles up and presents itself as either a HTTP 500/502 response with some meaningful message. The way we have implemented this is fine and I don't have an issue with it, however, currently we are generating HTTP 404's in exactly the same way, and this is a major problem because a 404 is not exception worthy.
So, what strategies do you use to deal with this kind of situation? Do you have a common architecture which you have successfully implemented to deal with this without polluting your core domain with entity or representation logic? What do you return from your repository layer so that your domain layer can continue to function correctly irrespective of whether there is data there or not?
Some possible solutions I am thinking about
- Use of a NullObject pattern
- Ensure there is always an id I can have a null value for
Whatever I do needs to be really easy to read and follow.
Thanks in advance for any help, advice or opinions you provide.
Why is a 404 not exception worthy? The user asked for something that they expect to be there, and it isn't. That is an exception. You cannot proceed with the code as designed.