I was tasked with revisiting an old application and refactoring its code to better log/handle errors.
This application is a .NET MVC API written in C# that handles readonly data. Since it is readonly I originally thought it was a good candidate for using Null or Special Case Objects, when returning data from the service layer. The problem is when an error happens creating these special case objects application behavior should be affected. It is an API it should return relevant HttpStatus Codes. This means behavior needs to change not only at the source of the exception but also during presentation of the response.
I have seen code that uses explicit type checking or does object inspection to determine whether application behavior should change. Making type checking regular practice seems especially bad in C#. I'm also hesitant about using domain objects to determine state it seems like blurring responsibilities, even if they are special case.
I believe I am going to go with a different solution, probably a generic response wrapping the actual data payload. However I now am wondering are there any good cases anyone can think of where one would still want to use a Null or Special Case Object to handle exceptions, when exceptions require a change in application behavior past where the exception occurred.
After exploring the possibility of using Null or Special Case Objects it seems like its uses are limited to when application behavior is completely independent of the response you might get from a service/method call. If it is required to act differently I can't see myself using Null or Special Case Object. If anyone has had different experience please let me know, because it seems this is a common pattern and I may be missing/misunderstanding something.