Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
Why would a module know a TextBox, in the first place? –  devoured elysium Aug 5 '11 at 13:16
Convert.ToDateTime() throws an InvalidFormatException if it cannot successfully parse the value entered into the textbox. Catch the exception and ask the user for valid input. –  Robert Harvey Aug 5 '11 at 15:54

4 Answers 4

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.

share|improve this answer
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 5 '11 at 15:58
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 5 '11 at 17:09

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.

share|improve this answer
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 5 '11 at 12:18
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 5 '11 at 12:20

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.

share|improve this answer

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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