Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Re: Percentage of error checking code

Reply
Thread Tools

Re: Percentage of error checking code

 
 
Öö Tiib
Guest
Posts: n/a
 
      02-26-2013
On Sunday, 24 February 2013 13:43:51 UTC+2, Giuliano Bertoletti wrote:
> this might be a too generic or even an ill-posed problem, but I'll try
> anyway.


It is too generic.

> Is there any study/document/pubblication which shows which percentage of
> C++ code (measured in lines of code) is used to perform error checking
> (validating parameters, catching exceptions, etc.)?


Validating parameters for contract violations? Programming errors?
Less than 10%. Automated tests? Can be several times more code than actual
application code. Can be none. Significant part of it can be generated by
tools.

Catching exceptions is usually called exception handling not error
checking. Exceptions do not mean programming errors. "etc." makes it
possible to name even diagnosing user-entered data for errors as "error
checking" and that is not too far from "preventing users from entering
erroneous data" that is usually one of the major goals of user interfaces.

> This might actually be dependent on the application type, but I would
> like to have some figures possibly per application type (or other
> factors as well).


C++ does not have clear separation of errors. So ... if you ask for
"checking errors" but mean "solving problems" then very large amount
of applications are entirely written for to solve someones problems.
 
Reply With Quote
 
 
 
 
osmium
Guest
Posts: n/a
 
      02-26-2013
"Öö Tiib" wrote:

> On Sunday, 24 February 2013 13:43:51 UTC+2, Giuliano Bertoletti wrote:
>> this might be a too generic or even an ill-posed problem, but I'll try
>> anyway.

>
> It is too generic.
>
>> Is there any study/document/pubblication which shows which percentage of
>> C++ code (measured in lines of code) is used to perform error checking
>> (validating parameters, catching exceptions, etc.)?

>
> Validating parameters for contract violations? Programming errors?
> Less than 10%. Automated tests? Can be several times more code than actual
> application code. Can be none. Significant part of it can be generated by
> tools.
>
> Catching exceptions is usually called exception handling not error
> checking. Exceptions do not mean programming errors. "etc." makes it
> possible to name even diagnosing user-entered data for errors as "error
> checking" and that is not too far from "preventing users from entering
> erroneous data" that is usually one of the major goals of user interfaces.
>
>> This might actually be dependent on the application type, but I would
>> like to have some figures possibly per application type (or other
>> factors as well).

>
> C++ does not have clear separation of errors. So ... if you ask for
> "checking errors" but mean "solving problems" then very large amount
> of applications are entirely written for to solve someones problems.


People often say "error" when a better word choice would be "anomaly"

I fiddled with a great circle distance program a few years ago that seemed
to be above 90% in checks of various sorts. Northern hemisphere vs.
southern hemisphere, only 360 degrees in a circle, on and on and on. I
finally threw it away in disgust. The "program" part of the program was
miniscule, it was all about data validation and GUI.


 
Reply With Quote
 
 
 
 
Stefan Ram
Guest
Posts: n/a
 
      02-26-2013
"osmium" <(E-Mail Removed)> writes:
>I fiddled with a great circle distance program a few years ago that seemed
>to be above 90% in checks of various sorts. Northern hemisphere vs.
>southern hemisphere, only 360 degrees in a circle, on and on and on. I
>finally threw it away in disgust. The "program" part of the program was
>miniscule, it was all about data validation and GUI.


I think that's a typical case. (Therefore, my previous answer.)

>People often say "error" when a better word choice would be "anomaly"


Or »derivation from the expectations of the programmer«
or »derivation from the intended path for success of the program«.

 
Reply With Quote
 
Victor Bazarov
Guest
Posts: n/a
 
      02-26-2013
On 2/26/2013 8:23 AM, Stefan Ram wrote:
> "osmium" <(E-Mail Removed)> writes:
>> People often say "error" when a better word choice would be "anomaly"

>
> Or »derivation from the expectations of the programmer«
> or »derivation from the intended path for success of the program«.


Do you mean "deviation"?

V
--
I do not respond to top-posted replies, please don't ask
 
Reply With Quote
 
Stefan Ram
Guest
Posts: n/a
 
      02-26-2013
Victor Bazarov <(E-Mail Removed)> writes:
>On 2/26/2013 8:23 AM, Stefan Ram wrote:
>>"osmium" <(E-Mail Removed)> writes:
>>>People often say "error" when a better word choice would be "anomaly"

>>Or »derivation from the expectations of the programmer«
>>or »derivation from the intended path for success of the program«.

>Do you mean "deviation"?


Yes.

 
Reply With Quote
 
Öö Tiib
Guest
Posts: n/a
 
      02-26-2013
On Tuesday, 26 February 2013 15:15:39 UTC+2, osmium wrote:
> I fiddled with a great circle distance program a few years ago that seemed
> to be above 90% in checks of various sorts. Northern hemisphere vs.
> southern hemisphere, only 360 degrees in a circle, on and on and on. I
> finally threw it away in disgust. The "program" part of the program was
> miniscule, it was all about data validation and GUI.


I see such result most often when people try to do things they are not (or
on worst cases can not be) capable of doing.

For example in the light of OP question they try to fix programming
errors runtime. It is impossible task since programming errors are in the
part that "fixes" too. Endless recursive effort may be wasted into it.

For more general example they try to solve a complex problem (or
impossible one) but fail. They initially allow input that is far wider than
the program is capable to solve. That results with huge code of diagnosing
and explaining why particular input is outside of capabilities of the
(often disgustingly simple and naive) algorithm.
 
Reply With Quote
 
Stefan Ram
Guest
Posts: n/a
 
      02-26-2013
Öö Tiib <(E-Mail Removed)> writes:
>I see such result most often when people try to do things they are not (or
>on worst cases can not be) capable of doing.


Let's take this amateurish example program to divide two
numbers in BASIC:

10 INPUT X,Y
20 PRINT X/Y

. These are two lines with about 24 characters. Now, someone
show me a commercial grade program with a GUI and error
checks to do this in C, C++, or Java that has less than
about ten times as much code (i.e., less than about 240
characters).

 
Reply With Quote
 
Öö Tiib
Guest
Posts: n/a
 
      02-26-2013
On Tuesday, 26 February 2013 17:20:57 UTC+2, Stefan Ram wrote:
> �� Tiib <(E-Mail Removed)> writes:
> >I see such result most often when people try to do things they are not (or
> >on worst cases can not be) capable of doing.

>
> Let's take this amateurish example program to divide two
> numbers in BASIC:
>
> 10 INPUT X,Y
> 20 PRINT X/Y
>
> . These are two lines with about 24 characters. Now, someone
> show me a commercial grade program with a GUI and error
> checks to do this in C, C++, or Java that has less than
> about ten times as much code (i.e., less than about 240
> characters).


Why? Always use some script language in pair with compiled language
for such throw-away tools and tests.

Also, if what you need is result of operating system command (like
"dir" or "ls -l") then do not write program at all. Write the
operating system command.


 
Reply With Quote
 
Öö Tiib
Guest
Posts: n/a
 
      02-26-2013
On Tuesday, 26 February 2013 20:51:34 UTC+2, Paavo Helde wrote:
> Öö Tiib <(E-Mail Removed)> wrote in
> news:(E-Mail Removed):


> > For example in the light of OP question they try to fix programming
> > errors runtime. It is impossible task since programming errors are in
> > the part that "fixes" too.

>
> For programming errors there are various asserts. Incidentally, it appears
> our codebase contains slightly more assert lines than throw lines.


I have found that asserts offer dangerous feeling of safety if compiled
out in release. So I often suggest to not define NDEBUG.

Other option is to replace asserts with throwing exceptions that may not
be caught without re-throwing. Standard library already throws such like
logic_error, domain_error, invalid_argument, length_error and out_of_range
so behaving in same way is more uniform. If it throws into face of client
then that is our fault (fault of our QA) and clients who bought from
losers like us deserve it. I must admit it rarely happens.
 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      02-28-2013
On Tuesday, February 26, 2013 6:51:34 PM UTC, Paavo Helde wrote:
> Öö Tiib <(E-Mail Removed)> wrote in


> news:(E-Mail Removed):


> > For example in the light of OP question they try to fix
> > programming errors runtime. It is impossible task since
> > programming errors are in the part that "fixes" too.


> For programming errors there are various asserts.
> Incidentally, it appears our codebase contains slightly more
> assert lines than throw lines.


And what about error checking that uses neither asserts nor
exceptions?

Or more generally: what about a program that uses the classical
line oriented input idiom:

std::string line;
int lineNumber = 0;
while ( std::getline( file, line ) ) {
++ lineNumber;
std::istringstream parser( line );
if ( parser >> i >> j >> k ) { // For example...
// ...
}
}

What part of that code is "error handling"? Without any error
checking, it might be simply:

while ( file >> i >> j >> k ) {
}

No need to keep track of the line number, for example, if I'm
not going to output it in case of an error. No need for the
separate `std::istringstream` if I don't need to check the
format, and resynchronize in case of an error. And so on.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: Percentage of error checking code Jorgen Grahn C++ 4 02-28-2013 05:10 PM
Re: Percentage of error checking code Stefan Ram C++ 0 02-24-2013 02:51 PM
needed percentage James MCSD 3 05-12-2004 03:34 PM
Percentage of switched vs. non-switched Ethernet Networks ??? Chris Cisco 8 04-15-2004 09:56 PM
Percentage C# vs VB.NET Justin MCSD 2 07-25-2003 11:40 PM



Advertisments