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. 14 2217
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 schrieb: 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.
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.
"Stefan L" <sl****@pp-software.REMOVEIfNoSpam.de> wrote in message
news:%2****************@TK2MSFTNGP14.phx.gbl... 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 schrieb: 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.
> 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
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/manual...logy/contract/
HTH,
Stefan
Steve McLellan schrieb: 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
Julia wrote: 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)
--
Hans Kesting
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
Julia schrieb: 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.
"D. Arndt" <d_*****@informatik.uni-kl.de> a écrit dans le message de news:
cv**********@news.uni-kl.de... 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
--
Joanna Carter
Consultant Software Engineer
In the world of TDD is there a place or needs for DBC?
"Julia" <co********@012.net.il> wrote in message
news:ON*************@TK2MSFTNGP15.phx.gbl...
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.
Julia <co********@012.net.il> wrote: 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.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Jon Skeet [C# MVP] schrieb: Julia <co********@012.net.il> wrote:
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.
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 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.
D. Arndt <d_*****@informatik.uni-kl.de> wrote: 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
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?
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
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?
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
Thanks for all of you, I have learnt a lot from this thread.
"Jeff Louie" <je********@yahoo.com> wrote in message
news:uN**************@TK2MSFTNGP14.phx.gbl... 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?
*** Sent via Developersdex http://www.developersdex.com *** Don't just participate in USENET...get rewarded for it! This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: varois83 |
last post by:
Hi
Newbie here. I have been working on creating a guestbook for my site as
practice and am learning a lot.
Do you guys validate your forms first on the client with javascript and
then on the...
|
by: c676228 |
last post by:
Hi everyone,
I just realized that it's so important to validate each string, I mean
'each' before you insert data from asp page into database.
I guess some customers just copy data from some...
|
by: Mike Hofer |
last post by:
Please forgive the cross-post to multiple forums. I did it
intentionally, but I *think* it was appropriate given the nature of my
question.
I'm working on an open source code library to help...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
| |