I asked everyone and generally have gotten different responses from everyone.

Now, having a variable that could be NULL in, say, Java, requires to handle that case generally speaking. We can do something like:

if(myVarThatCouldBeNull != null) {
   myVarThatCouldBeNull.getSomeValueFromMyVarThatCouldBeNull();
}

...Such that the getter method is only called when the var has a value (else a Null Pointer Exception (NPE) would be thrown).

My question is, for variable that absolutely should never be NULL, say you have an Attendance application (let's call it API X) that is used to automate taking attendance in school. You could have a Student model/object like such:

public class Student {
   private String firstName;
   private String lastName;
   private String email;
   private Integer id;
}

... Now we could assume or say, that in-order for students to have their attendance "logged", API X reads/consumes the fields/properties of the Student model/object as JSON key/value pairs POST'd from some API (we'll call this API Y). API X then deserializes the request from the API.

Since we already said the id is needed to log attendance, and a core-functionality of API X, it should never be NULL. This can be because, maybe there is a UI webpage with an input form to create the student account, and the id field is a required input field where students enter in their id from their school ID, else they cannot complete registration (no user account is created, thus no data sent to the backend applications, in this case, API X which would consume the request).

My question therefore is - In these cases (the latter), should developers/devs still be null checking the id field? My first thought is that it is redundant, but then again, it's only the developers assumptions that it is not needed. What if there is an edge-case out there that will break the API (API X), that we, the developer/dev is unaware of and because we are relying on our assumptions (and not fully committing to null-checking every variable), we would run into issues later on?

Then again, I could also see (and have seen) a codebase with if(...) wrapper functions for NULL checks as being unnecessarily verbose, and obfuscates the codebase and flow.

If everyone just assumed certain things didn't need null checks, I feel as if no-one would do null checks. But, is it really necessary to wrap variables with conditionals e.g. if-statements, like ones in this example involving an id that is input by a user on a UI input form, and that the student account cannot be created without that id being input at the UI level? (backend systems would consume this later on downstream)?

I potentially overcomplicated this, but I was generally curious, would love to hear everyones responses

CodePudding user response：

you cannot trust data sent from user, never

usually you have multiple layers in application:

1. controller which is actually accepts user input and should perform validation, including all null/not null checks
2. internal class which actually performs some work - this one can rely on upper level to supply valid data and thus omit validation

CodePudding user response：

All client-facing API (the same is valid for libraries if they have restrictions on incoming data/setup/etc.) should perform validation on incoming data (even if the client is actually another service in your system in case of distributed ones). What is absolutely evident for your can be not that clear/evident to another user/developer even if we discard malicious intentions.

After the incoming data was validated though - it depends on how your application is written and structured, but there you can lax the checks, at least to some extent (i.e. usually there is less sense to revalidate already validated data).