3

I use .Net and C#.

I have the following code in some module:

DateTime validFrom = Convert.ToDateTime(validFromTxt.Text);

This makes (in my opinion) the implicit assumptions

  • that there is text in validFromTxt.Text
  • that it is possible to convert this into type DateTime.

My question is, may the module make these implicit assumptions (due to "knowledge" of context of the page) or would it be better to check them before the command?

ChrisF
  • 38,938
AGuyCalledGerald
  • 173

4 Answers4

6

In my opinion, modules are allowed to make assumptions if they are explicitely documented in the module documentation/method description.

This is a major concept of Design by contract. Define contracts between your different modules to establish the responsability of each one.

In your case, you might decide that all validations are the responsibility of your module. In which case all other modules can invoke yours without previous checking. But you night as well decide that your module is very simple and suppose that the date has to be checked in another module, in which case you can make the assumption that the date is valid. But you NEED to precise in the documentation that unexpected behaviour (exception, incorrect result) might happen if the date is invalid.

In the end, it is just about distributing the responsibilities in the modules of your application and ensuring that all modules respect their contracts.

Vivien Barousse
  • 231
  • Agree, but with care. Making asumption is sometime the sign of bad design, so you have to ask yourself the question each time : is it legitimate to make the assumption ? yes -> doc, no -> refactoring. When you choose yes, you must have a strong point to support that choice. – deadalnix Aug 05 '11 at 15:58
  • 1
    A typical example to support this concept is the case of the binary search. You have to assume that the array you are given is sorted. The reason for that is that binary search runs in O(log n) time, and checking if the array is actually sorted is O(n). Checking the parameters would make the algorithm less efficient. – Vivien Barousse Aug 05 '11 at 17:09
5

Unless you can guarantee that your input is valid you must verify it. How you do that depends on your scenario. Given that it's highly unlikely that you'll always get valid input - we're dealing with humans here after all - then some sort of validation is required.

If you know that most of the time the input is going to exist and be valid then using exception handling around the conversion is probably the way to go. This means that the normal operation of the code will be the quickest it can be.

If you know that a lot of the time the input will be invalid then you should probably check it before trying to convert it. This means that while there is an overhead in processing correct input, incorrect input is also handled efficiently.

ChrisF
  • 38,938
  • In this case, I control the input by using .net-validators. Of course I know these validators work because I have tested them. But I am know sure whether I may rely on there existence because they could break or be removed for some reason. I do not want the module to break for any reason. – AGuyCalledGerald Aug 05 '11 at 12:18
  • 1
    That's actually a different question. You are actually doing what I suggest. If you are using a tool then you have to assume it works (until proved otherwise). – ChrisF Aug 05 '11 at 12:20
2

No assumptions should be made. The input is in the form of a text box which is just a string. Reading any value from the text box should not assume anything. If the unput is supposed to be a date, then a validation routine is necessary to validate that the string is really a date before passing it along any further.

As a recommendation, I suggest to replace the textbox with a DateTimePicker or other date time control. This will allow the users to still pick a date, but the value is not a string but a .Net DateTime object. Then there is no assumption as the control has the data in the format required from the start.

Jon Raynor
  • 11,421
0

As there is validFromTxt object you can try convert text to date, but you never ever ever should assume that user data is valid. Try convert and catch exception if it occurs.

Dainius
  • 340