Basically as the title says. Say we have an API endpoint that takes some object as a parameter and passes that object into a service method. That service method then relies on a mapper class to map the object to another type. This leaves three places to check if the object is null:

  1. Beginning of the API function
  2. Beginning of the service function
  3. Beginning of the mapper function

It seems overkill to perform a null check three times, but there is no guarantee that the service function will only be used by that one API function and no guarantee that the mapper function will be used only by the service function. I was curious what others considered to be best practice in this situation. Thanks!

  • 3
    Well the best way to use a non-nullable variable. If it's just a mapper class, why not just map the null value to the target? Aug 21, 2020 at 18:57
  • @RobertHarvey Do you mean just returning null? Or returning an "empty" object, i.e. not null but has no properties set?
    – Odd822
    Aug 21, 2020 at 19:31
  • Which way is most faithful to the properties found in the original object? Aug 21, 2020 at 19:34
  • Also, what are your design requirements? If your requirements say that one of the responsibilities of the mapper is turning nulls into empty objects, then that's what you do. If your requirements say that the mapper merely passes through whatever it is mapping, then that's what you do, nulls and all. Aug 21, 2020 at 19:38
  • Does this answer your question? When should pointers be checked for NULL in C? Nov 10, 2023 at 22:47

4 Answers 4


You should check that a parameter is not null whenever* you write a method that cannot process with a null value. If that means it gets checked 3 times, then so be it. Some languages have a specific exception for this case (e.g., ArgumentNullException in C#), which is an appropriate course of action when a null parameter is encountered.

If your method can process as normal with the null value, there's probably no need to check it. As Robert Harvey mentioned in the comments, if you can add a mapping from a null value to the correct target, go with that and there is no need to check for a null parameter. If you can't add that mapping (e.g., a null value doesn't make physical sense), then check the parameter for null first.

  • Typically this only applies to public methods. While you know that you've checked the value for null in the API function, the service function won't necessarily always get called from the API function, as you said. You control the usage of private methods much more tightly, so there is not as big a concern that they get used differently than originally written.
  • 1
    You should also check for null before dereferencing a variable that might contain null. Aug 21, 2020 at 19:35
  • 1
    ...unless throwing a null pointer exception is your desired behavior. Aug 24, 2020 at 10:15
  • You might have a situation where a parameter may be null in some cases but not in others. Null check when null is acceptable would be incorrect. So you need to check only when null would be unacceptable.
    – gnasher729
    Nov 11, 2023 at 18:12

Unless you use functional programming features Optional monad, you will always have to check null, which it brings to fraudulent coding style: when you see any methods starting with if(param!=null){...)} which is redundant but is a must, and it affect readability of your code.

So if you see all this kind of code and you are one of the few that things it should be better, I suggest to switch to functional programming.


Depending on which technical stack/framework you are using, many frameworks validate out of the box and at the edge. What I mean by at the edge, is that before any your function(s) gets called internally, the message/object/data transfer object (DTO) is validated.

By doing this, you only have to do the validation once, which I think is a good thing and would recommend (fail fast). Also, whoever is calling your service gets a validation error, so they know they are not meeting an expectation of your API in regard to the data being sent. If your using rest, it's usually a bad request message (400) error that is returned.

As an example, the NestJs framework handles this with a built-in class-validation pipe. Then, simply mark up the DTOs as needed, and the incoming message will be validated. This avoids multiple checking and verifies that data coming in is meeting your expectations and avoid cluttering your code with additional NULL checks. Please note, many frameworks/tech stacks offer similar functionality, and this example is merely for illustration purposes.


You should check for null wherever the variable's value is actually used. If the API, service, and mapper all perform some operation on the value stored in the variable, you must check for null in all three instances to avoid a potential error.

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.