By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,627 Members | 2,244 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,627 IT Pros & Developers. It's quick & easy.

Argument Checking

P: n/a

Does anyone have any coding rules they follow when doing argument checking?

When arguments fail during check, do you return from the call with an
ambiguous return value, or do you throw exceptions?

Aug 8 '06 #1
Share this Question
Share on Google+
4 Replies


P: n/a
Patient Guy wrote:
>
Does anyone have any coding rules they follow when doing argument
checking?

When arguments fail during check, do you return from the call with an
ambiguous return value, or do you throw exceptions?
Hi,

I guess everybody have their own coding rules.
I am not aware of some RFC-like proposal on how to handle it, and if it
existed, I wouldn't care. ;-)

Bottomline is: What do YOU (or your boss/custumer) want to check?

This is how I do it most of the time:
1) In the form I make clear to the visitor which elements I want to be
filled in.
2) When submitting, check the values.
If they are ok: just submit
If not, do not submit, and make an alert saying "Please give your first
name" or something like that.

And most important: Do NOT rely on Javascript when accepting formvalues on
the server. Always recheck them at the server.

So yes, this is always double work, but once you've done it a few times,
you'll get very quick and maybe use a few prefabbed functions (on both the
server and in Javascript).

Be wise and first discover how to check values yourself before using some
downloaded script of somebody else. :-)
I have seen a lot of bad checkingalgoritms on the net.

Regards,
Erwin Moller

Aug 8 '06 #2

P: n/a
Patient Guy wrote:
Does anyone have any coding rules they follow when doing argument
checking?
When arguments fail during check, do you return from the call with an
ambiguous return value, or do you throw exceptions?
Depends on what you want to do.

IMO, you should usually skip argument checking altogether. The person using
a function should know what arguments to pass. Checking them each time a
function is run only (potentially) slows things down.

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com
Aug 8 '06 #3

P: n/a
"Matt Kruse" <ne********@mattkruse.comwrote in comp.lang.javascript:
Patient Guy wrote:
>Does anyone have any coding rules they follow when doing argument
checking?
When arguments fail during check, do you return from the call with an
ambiguous return value, or do you throw exceptions?

Depends on what you want to do.

IMO, you should usually skip argument checking altogether. The person
using a function should know what arguments to pass. Checking them
each time a function is run only (potentially) slows things down.
If you write code that might become a library distributed to others, they
might very much appreciate argument checking, or else they might be forever
trying to figure out their bug.

I wrote a longer version of this message with an example function that I
wanted comment on, but the length of the message likely scared off those
with even the longest attention spans.

You can find the message here:

<news:Xn******************@207.115.17.102>

There are probably good reasons to do argument checking anyway even if you
are using the code for your own purposes. Wouldn't it actually help you
debug faster or force you to work a better design in creating functions?
Aug 8 '06 #4

P: n/a

"Patient Guy" <sevisen.adam@gmailDOTHEREcomwrote in message
news:Xn******************@207.115.17.102...
>
Does anyone have any coding rules they follow when doing argument
checking?
I've some general guidelines that I follow.

Firtly I would define "arugment checking" as dedicated code to determine the
existence of an argument and optionally it's type, format or content and
react according to need. The reaction might be to default the value of the
argument, throw an error or just plain ignore it.

Generally I WILL perform argument checking when:

+) The code in question is a "black box" of functionality. Components and
libraries designed to be imported and used by others should, I believe,
assume no special or deep knowledge of the code's inner workings. Argument
existence and type checking should be done and appropriate (and clear) error
messages provided.

In general the more any piece of code (function, method, custom object, etc)
is aimed at re-use the more formal I'll get about argument checking.

+) The code in question accepts end-user-generated ("uncontrolled") input.
When the code in question can accept uncontrolled input (as from a form
field perhaps) you should make it a point to check the argument. Almost all
field validation can be seen as a kind of "argument checking" (or maybe more
accurately "parameter checking").

Never trust a user.

+) When data-typing is required. Does your method require a number? An
array? A date? If so it's a good idea to check the input to make sure
you're getting what you know you need.

+) When the arugment is optional (especially when it's optional and can be
set to a default). Arguments are often optional, argument checking will
tell you if these optional arguments have been passed or not so that your
code can react appropriately. In many cases you may want to default the
value of these optional parameters (for example an optional string might
better be set to a blank space rather than left as undefined).

+) Whenever failure to check the argument can cause things to go belly up.
This is pretty simple but why let your code get (possibly) deep into a
(possibly time-consuming) process only to discover that an argument is
wrong/missing/hosed in some way? Better to check up front an react quickly
in my opinion.
I will generally NOT perform argument checking when:

+) The code is "automated" and called only by formalized code. For example
I prefer in some cases to provide generic eventhandlers: onChange and
onFocus and so forth that take a form field as an arugment. Since these are
called only by form field-specific event handlers in the form of
"onChange(this)" there really isn't much of a need to check the argument.

+) When the code is so simple that any error will both be quickly encoutered
and just as illuminating as any custom one provided.
Most of the time however I'll lean towards full, formalized argument
checking.
When arguments fail during check, do you return from the call with an
ambiguous return value, or do you throw exceptions?
It depends. As a general rule it's a good idea in most cases. For me I
look at the method/function as a series of questions and resulting
statements (flow chart style). This is why it's best to define (write a
specification) for your code beforehand: the answers will be in there.

For example consider a function "parseDate(Input)". The function takes a
value and tries to convert it to a date - if it can, it returns the date, if
not it returns null. Your specification has the answer: anything that can't
be converted to a date results in null.

Considering that I would check the input argument and if it's not a string
return null immediately. You _could_ return an error that says "a string is
required" but that adds unneccessarily to the definition.

In this case the usage is easier as well. You don't have to wrap
parseDate() in try/catch blocks every time you use it.

On the other hand sometimes an error is needed. Consider a function
countVowels(Input) which takes a value and returns the number of vowels in
it.

Here the spec doesn't define an "out" - you have to return a number. Since
asking for the number of vowels in, say, an integer value, is nonsensical
(returning "zero" this case would be misleading, I think) I would throw an
error for all non-string input. You'll either get an error or a number.

All told its best to find a style and stick to it even if it's sometimes
counter intuitive. Consistency helps you more in later maintenance more
than almost anything else.

Jim Davis
Aug 8 '06 #5

This discussion thread is closed

Replies have been disabled for this discussion.