Sanity checking in the Called or by the Caller ?

[Kevin Powick]

This particular question came up in another programming group and I was wondering what the take on it is by MV people.  The question being, "Do you do your sanity checking on variables passed to a subroutine or function within that subroutine/function or before the variables are passed to it?"

Examples of such "sanity checking" would be asserting things such as variable assignment, value, range, etc. 

--

Kevin Powick 

[Dan McGrath]

In the interest of DRY, sanity checking should be within the subrountine/function. This is also a good defensive coding strategy (don't trust what is passed to you).

This is essential when writing a library or API.

This doesn't mean sanity checking cannot be done in the caller as well.

--
You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com
To unsubscribe, email to: mvdbms+un...@googlegroups.com
For more options, visit http://groups.google.com/group/mvdbms

[Mike Preece]

I agree with Dan.

[Tony Gravagno]

I do everything on the server in the initial development. If I get an
opportunity to go for a second round of quality control, I'll add
handling into the middle tier. If I get a chance at a third round I'll
experiment with pushing more out to the client. The goal is to put
sanity checking wherever it's most performant. Some people say "why
don't you put it all in the most performant location in the first
place?" Well, I never know where that is going to be - it depends on
the tools being used and how rigorous the checking needs to be. Coding
such things into the client and middle tier cost more in terms of
time=money, and it's easier=cheaper to do it on the server, but the
app is always slower when we go all the way to the back end to find
out some data is invalid.

That's the trade off. My clients want performance but they also want
fast and low-cost development. If you want the cost down, the first
round is good. If you want it performant, let me take another shot at
shifting some of the rules, but it's going to take time=money to
improve the performance.

So my answer is: always do it on the server, but if you can to do it
further up the chain too (not instead of, in agreement with Dan), the
app will be more user friendly and the client will ultimately be
happier with the product.

T

On Jan 14, 11:54 am, Kevin Powick <kpow...@gmail.com> wrote:
> This particular question came up in another programming group and I was

> wondering what the take on it is by MV people.  The question being, "*Do

> you do your sanity checking on variables passed to a subroutine or function

> within that subroutine/function or before the variables are passed to it?"*
>
> Examples of such *"sanity checking"* would be asserting things such as

[Ian Perkins]

Probably this came up on the other forum but one possible approach is Design by contract

DBC specifies preconditions which the called routine must verify and postconditions which it must conform to (as well as invariants which must always be true no matter what). This should lead to a consistent API design where all parties understand their responsibilities.

 

IMHO, this is contrary to Tonys assertion that 

The goal is to put sanity checking wherever it's most performant

as this seems to lead to a software design where validation is scattered based on arbitrary and shifting rules  (not such a problem for a one-man/very small team but a maintenance nightmare for big projects which are common in the T24 world).

Having said all of that, I have not (yet) worked in an organisation where any kind of design rule is mandated - it is left up to the individual programmer and therefore subject to knowledge, experience and whimsy.

[Wols Lists]

On 14/01/12 20:55, Mike Preece wrote:
> I agree with Dan.

I dunno.

Checking variables in the subroutine is inefficient, you could be
checking them multiple times. On the other hand, it's guaranteed safe,
the subroutine either returns a valid result, or fails cleanly.

Checking the variables as they come into the program is most efficient,
but a lot of grunt work and easily missed/forgotten/ignored. You don't
really want to sanity-check the contents of every record as you read it
:-( And it doesn't catch somewhere inside the program doing something
stupid and corrupting a variable.

Horses for courses.

Cheers,
Wol

[Tony Gravagno]

Looking back at my note I removed a couple sentences that were
apparently critical. *sigh*

There are at least two factors here, performance and security, but the
approach is the same, and still dependent on funding. My preference,
and industry standard recommendation, is that you validate on the
client _and_ in the rules. While related to performance, one of the
main reasons for this is what's known in the RDBMS world as "SQL
Injection". You want to filter out bad queries on the client, but you
Must filter on the server too because hackers strive to bypass the
intended client and inject queries directly into the database.

All I was saying is that since we Must validate at the server, I do it
there first, and move outward as the project allows. Usually
constraints are added through the tiers as development progresses, and
per the above I do try to get checks in at both ends. But when time is
constrained we don't always have that luxury.

As always YMMV.

HTH
T

On Jan 14, 9:50 pm, Ian Perkins <perkins....@gmail.com> wrote:
> DBC ... IMHO, this is contrary to Tonys assertion that

[David Morris]

On 14 Jan 2012, at 19:54, Kevin Powick wrote:

> This particular question came up in another programming group and I was wondering what the take on it is by MV people. The question being, "Do you do your sanity checking on variables passed to a subroutine or function within that subroutine/function or before the variables are passed to it?"
>
> Examples of such "sanity checking" would be asserting things such as variable assignment, value, range, etc.

(apologies Kevin P - I hadn't realised my mail client had picked up your direct email rather than the list address)

If I was to give the 'ideal' view it would be to check in the called simply because it's the last place you can make sure you're not pushing cruft in to the database. However, a lot of our code is web or J2SE based and it makes sense to put a layer of error checking in the client process simply to offer a quicker turnaround of errors to the end user.

The upshot is that our server layer tends to check relational stuff like missing order numbers, customers on stop etc and the UI tends to check the basic stuff like is there a customer code there, are numbers numeric. The API and server side doesn't then replicate these checks.

Of course, the difference for me is that I have full and exclusive control over both ends of the model. If I was writing APIs for consumption for the general public as well as my own dedicated UIs, I would take a different approach with a more robust checking regime on the server.

Off to band rehearsal now...

--
David Morris
e: da...@brassedoff.net
blog: http://www.brassedoff.net | twitter: @brassedoff

[Ian Perkins]

SQL injection? This is the best explanation I have ever seen...

http://xkcd.com/327/

[Kevin Powick]

On Sunday, 15 January 2012 00:50:15 UTC-5, ianp wrote:

.... I have not (yet) worked in an organisation where any kind of design rule is mandated - it is left up to the individual programmer and therefore subject to knowledge, experience and whimsy.

Yes, that does seem to be the case.  Looking at some of the older systems with which I work, I would say there is very little validation of input params within the methods (subroutines, functions, etc).

Even looking at my own work, I find that I've often approached the situation with the attitude of "it depends"; Meaning that if I'm creating a routine for "public" consumption then parameter validation within the method is usually much more thorough, but within local system code where I, or a team, is intimate with the project, then there is much less of that because one is expected to program "correctly". :)

I think the situation is universal among developers and certainly not limited to the MV world.  You can download some of the most popular and respected programming libraries in the world and find examples of methods with parameters that are not validated in any way.  I'm guessing the expectation is that as a developer using such libraries, you should know what you're doing. 

I can understand the mentality of the library developer that does not validate parameters.  They may be thinking along the lines of, "Here is a library that I've developed that performs some nifty function that either you don't know how to code and/or don't have the time to code.  It's not my job to hold your hand and make sure you don't pass garbage to it.".  There is also the argument of degrading performance by adding "unnecessary" checks.

To sum it up, I agree with Dan M.'s answer, but while it may represent the ideal or preferred approach, I don't think that it's as cut and dried as that.

--

Kevin Powick

   

[Simon Verona]

After 25 years of developing and maintaining code, my experience is that the extra time spent at the front end adding checks in the subroutine is saved many times over in the total application lifecycle.

The other related issue is the quality and maintenance of documentation relating to the input and output for the subroutine.   This starts as full comments within the code - describing the function of the subroutine/function, the parameters to be supplied, the output and a description of the validation that takes place which may cause the routine to abort with an error.

These are important when working as a team of one, and the importance increases exponentially as the size of the team increases or if the function is consumed externally (eg as a web service)..

Just my two pennies worth..

Simon

Simon Verona 

--

[Jeff K]

Steve McConnell, author of Code Complete, agrees with Dan McGrath.  Specifically in chapter 8, Defensive Programming.  The key point McConnell makes is that "Garbage in, garbage out" is the sign of a sloppy, nonsecure program.  The only acceptable behaviors for production software is "Garbage in, error message out," "No garbage allowed in," or "Garbage in, nothing out."

In regard to the performance issue, correct behavior is the first priority.  It doesn't matter how fast your code is if it produces incorrect results.

A bit OT, but Code Complete was a very enlightening read when I read it 18 years ago.  The above is just a very, very small example of what's covered.  While reading it, I thought many times over, "I wish someone would have told me that years ago!"  It has balanced discussions on many, many development topics, as opposed to the usual opinionated flame wars we often see online.  (Examples: "GOTO is evil!" and  "One return per routine!"  Both are exposed as rules of thumb that are usually correct, but often you can write code that's more "sight readable" and obviously correct by knowing when to break the rules.)

And, it's language-neutral, so even though the examples are in other languages, the concepts and discussion can be applied to MV just as well.  Highly recommended.

[Charlie Noah]

Hi Jeff,

I agree completely. Code Complete is one of the best books of its type (if  not the best) I've ever read. It is certainly applicable to most any type of programming, and should be read by every programmer.

I also agree that a routine (any routine, internal or external) should be very skeptical of data passed to it. What it does about it depends on the circumstances, of course, but it should never just trudge along like everything is OK and fail, or worse yet, return incorrect results without complaint. That could result in an incorrect money total (bad enough in itself if it's my money), or someone dying because they depended on a critical result. My priority list goes something like this:

Software should
1. Do the job correctly, every time, no matter what's thrown at it (sometimes that means saying "uh uh, no dice, that data's no good, do it again")
2. Do the job in a timely manner (variable depending on circumstances such as real-time signal analysis, online data entry or a background batch process)
3. Be easy for the user to use (preferably without whipping out a manual)
4. Be easy to read, understand and maintain

Sometimes 3 and 4 are equal or even change places, again depending on circumstances.

I'll get off my soap box now. ;^)

Regards,
Charlie Noah