That's a step backwards. Code error checking should be done as early as possible. In order of earliness:
* Typing in the code. (Ideal: it is clear from the syntax that the code performs X instead of Y.)
* Compiling. (Strong type checking ensures you cannot return 5.3e7 or null from GetHostName.)
* Running the code at all. (Code contracts and assertions trigger if GetHostName returns "".)
* Automated unit tests. (Check that DB.GetHostName() returns the same string given to DB.Connect().)
* Automated integration tests. (Check that the DB module can connect to and retrieve useful data from a dummy database.)
* QA ("Hey Joe, the system hangs when I give "ยค;\@" as my username and press the connect button rapidly for a few seconds.")
* Customer ("Hi the system has a problem, please fix.")
The further up, the faster, more accurately and with less "noise" the error can be discovered.
That's a step backwards. Code error checking should be done as early as possible. In order of earliness:
* Typing in the code. (Ideal: it is clear from the syntax that the code performs X instead of Y.)
* Compiling. (Strong type checking ensures you cannot return 5.3e7 or null from GetHostName.)
* Running the code at all. (Code contracts and assertions trigger if GetHostName returns "".)
* Automated unit tests. (Check that DB.GetHostName() returns the same string given to DB.Connect().)
* Automated integration tests. (Check that the DB module can connect to and retrieve useful data from a dummy database.)
* QA ("Hey Joe, the system hangs when I give "ยค;\@" as my username and press the connect button rapidly for a few seconds.")
* Customer ("Hi the system has a problem, please fix.")
The further up, the faster, more accurately and with less "noise" the error can be discovered.