Monday, September 22, 2014

I'm...not going to let you do that

I was currently working on some error handling code for one of my side projects when I came across this problem. I have objects stored in a database, which of course has a field Id for its primary key. However, when the user goes to create this object, the Id field has no value until it gets saved to the database, as which point the database engine gives it an Id. The object in my code includes a member for the Id field of type int? (which is a nullable int, it can have a value of null). The function I use to get the object from the database is defined as such

     public Object GetObjectFromDatabase(int? ObjectId) { }.

Inside this method, if the value of ObjectId was null then I would return null as the object.

     if (ObjectId.HasValue)
     {
          // Get and Return the object
     }
     else
     {
          return null;
     }

Adding in my error code, I thought about that behavior and decided that if I was going to the database to get an object, I would need to know its Id, so I decided that passing in a null would be considered an error. So I changed that else statement to read

     else
     {
          throw CustomizedError;
     }

I still wanted the function to accept a nullable int to avoid checking if there was a value for Id and then convert it to a regular int for every place I call GetObjectFromDatabase. I have other functions that take in similar parameters, including updating the object, deleting the object, and other various things that can be done with the object, After some debate with myself, I changed those functions to only accept a regular int instead of a int? for three reasons.

1) Programmers can only make mistakes when the code allows them to. This is why we have private variables and enforced type checking. In languages like Javascript, bugs arise when strings get treated like numbers and vice versa. Javascript doesn't force the programmer to choose a type for thier variable and stick with it. It's just var Name; Take the following code
  
     var Two = 2;
     var Three = "3";
     alert(Two + Three);

The pop up you get will display "23". This would be a bug if the developer wanted 5. It's a simple mistake, but it happens because it was allowed to happen. If you tried that in C#, you wouldn't be able to compile. If I don't want programers to pass a null into this functions, I just need to not let them at all.

2) Bugs make it through testing all the time. I or someone else will eventually make the mistake of passing a null into that function, and, if I had testing for my project, since it would be a special case there is a good chance it would make it through testing.

3) It is always better not to have to throw errors. Even if it means more code to write. Sometimes having to write more code means you have to think through what you are doing. Also, bug-free code is sort of the goal and writing code that actually prevents bugs before it even compiles is preferable.

No comments:

Post a Comment