Do you validate incoming parameters?

[Julia]

Hi,

When writing class library do you validate ALL incoming parameters?
Is this a good approach,to valid them ALL!!!,and throw exceptions?

I realize that if I am not validating them,than my logged exceptions ,raised
from objects or calsses which uses them,are some what more hard to dissect.

Thanks in advance.

 

[Stefan L]

I would say it's up to you whether you validate your parameters or not.
If you think it helps you finding errors and you have the time, then do it.

On the other hand you have to consider how time-critical your app is.
Param-Checking needs time, for programming it once and for the checking
at each time you call it.
That's way there's a principle of design-by-contract, meaning that a
routine only fulfills its task if the params fit the requirements, and
being undefined otherwise.

It of course is good practice to throw an ArgumentException with an
special description rather than maybe a NullPointerException or similar
somewere when hitting the critical code and then not finding the reason.

Best way is to differentiate between errors that *could* occur at
runtime(production) and errors that *may* occur at designtime.

You can also use the Precompiler and check all arguments in debug-build,
and only for common errors at release-build.

HTH,
Stefan

 

[Julia]

Thanks

Is this a modern methodology? is it common to use it?
I don't understand why parameters checking is being neglected
mostly all the source code which I read on the internet doesn't have
parameters checking
why is so?

can you recommend book about this topic?

(I am writing in C#)

Thanks in advance.

 

[Steve McLellan]

Thanks

Is this a modern methodology? is it common to use it?
I don't understand why parameters checking is being neglected
mostly all the source code which I read on the internet doesn't have
parameters checking
why is so?

Hi,

It's not particularly modern; formal design methods emphasise pre- and
post-requisites, where the input requirements are specified and the output
results are guaranteed to conform to the specification if the prerequisites
are met. If they're not, it's not determined whether an error will be
flagged or the code just won't perform as specified. Personally, I like code
that deals gracefully with any realistic runtime problem, but as long as the
specification is clearly available to other coders, I don't think it's
reasonable (or useful) to check every parameter exhaustively.

The reason most code from the Internet doesn't check parameters is simply to
save space; it's not intended to be directly used in production code, but as
an example.

Steve

 

[Stefan L]

Hi Julia,

I agree with Steve, validate your parameters by checking for the most
common misuse and the ones with the most serious results (e.g. before
blindly formatting your hard disk you should do a validation... ;-))
But keep your code short and readable, the parameter checking should be
performed by the caller, who can do this more efficiently because he
knows what scenarios can occur.

For further info on DBC you may want to look at:
http://en.wikipedia.org/wiki/Design_by_contract
http://archive.eiffel.com/doc/manuals/technology/contract/

HTH,
Stefan

 

[Hans Kesting]

Hi,

When writing class library do you validate ALL incoming parameters?
Is this a good approach,to valid them ALL!!!,and throw exceptions?

I realize that if I am not validating them,than my logged exceptions ,raised
from objects or calsses which uses them,are some what more hard to dissect.

Thanks in advance.

I think it depends on how the method is used. Is it in a library that is
only used by you (and maybe a few others in your company), then you can
just place a note "make sure the parameters conform to .." and forget
about runtime checking. If it's a library that you want to sell to other
developers, you may want to use runtime checking (in addition to that note)

 

[D. Arndt]

Hi,

if this is for example(!) for code that performs a division and you want
to make sure the divident is != 0, then assertions are what you are
looking for; i am not perfectly sure which way they are implemented in
c#, but it should look something like this: assert (condition) : Error
Message; you can deactivate those for runtime, but leave them in your
code (thus have them in while coding, leaving them out when not needed
anymore).

Cheers

 

[Joanna Carter \(TeamB\)]

if this is for example(!) for code that performs a division and you want
to make sure the divident is != 0, then assertions are what you are
looking for; i am not perfectly sure which way they are implemented in
c#, but it should look something like this: assert (condition) : Error
Message; you can deactivate those for runtime, but leave them in your
code (thus have them in while coding, leaving them out when not needed
anymore).

Try looking at Debug.Assert(...)

Joanna

 

[Julia]

In the world of TDD is there a place or needs for DBC?

 

[Jon Skeet [C# MVP]]

When writing class library do you validate ALL incoming parameters?
Is this a good approach,to valid them ALL!!!,and throw exceptions?

I would suggest validating parameters for public and protected members,
but not for internal/private members. If you think the clients will be
worried about performance, you could make put checks within conditional
compilation blocks, and compile one version with error checking on and
one without.

 

[D. Arndt]

I would suggest validating parameters for public and protected members,
but not for internal/private members. If you think the clients will be
worried about performance, you could make put checks within conditional
compilation blocks, and compile one version with error checking on and
one without.

thats just what assertions are for, activate them when you need them,
else tell the compiler to not include them at all, or the jit to ignore
them o_O

 

[Bruce Wood]

I would advise a broader approach to this problem. All of the foregoing
comments are worthwhile, but there is still the problem of "when"?

Certainly if you are expecting programmers outside your company (or
even internally, if you work for a very large company) to use any of
your classes, then you must make them bulletproof. You should include
checks for validity _for those cases in which C# doesn't already throw
the appropriate exception_. For example, you should check for null
arguments and throw an ArgumentNullException rather than let the
framework throw a NullReferenceException.

In cases in which your code is strictly for internal consumption
(either within a small company or within a small group in a larger
company), you should choose logical layers in your code where you are
going to "firewall" against your own mistakes or those of other
programmers. For example, you may choose to "firewall" a commonly-used
DLL, because good error checking will save you debugging time.

Once you've chosen a firewall point... a DLL, for example... error
check the _entire public interface_ to that part of your system. Check
it as if it were for public release.

If you overdo the firewalling then your code will run slow. However, if
you underdo it, you will cost yourself more time in debugging later.

 

[Jon Skeet [C# MVP]]

thats just what assertions are for, activate them when you need them,
else tell the compiler to not include them at all, or the jit to ignore
them o_O

I use assertions to check that *my* code doesn't fail, not to check
that other people haven't passed in bad parameters.

Look at the framework libraries for examples - they all throw
exceptions when passed invalid parameters, rather than having an
assertion fail - why should 3rd party libraries be different?

 

[Jeff Louie]

Julia... Here is one take. If your library is mission critical then the
library should validate all preconditions. If efficiency is paramount,
then the preconditions should be validated once. Practically speaking,
this normally means the client will validate preconditions (design by
contract). An alternative design is called validation pre conditions
where the supplier validates the preconditions and the client agrees to
register an interest in the suppliers validation. This can be formally
implemented in a language that supports checked exceptions.

The decision to throw an exception is a _separate_ question. If the
supplier explicitly asserts a precondition in the documentation, then
the supplier should throw an exception if the caller violates the
precondition. If the supplier does not explicitly state a precondtion,
then the supplier should not throw an exception if the precondition is
violated, but should signal the error perhaps by returning null or
false.

http://www.geocities.com/jeff_louie/OOP/oop14.htm

Regards,
Jeff
When writing class library do you validate ALL incoming parameters? Is
this a good approach,to valid them ALL!!!,and throw exceptions?

 

[Julia]

Thanks for all of you, I have learnt a lot from this thread.