Re: Percentage of error checking code

Discussion in 'C++' started by Öö Tiib, Feb 26, 2013.

  1. Öö Tiib

    Öö Tiib Guest

    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.
     
    Öö Tiib, Feb 26, 2013
    #1
    1. Advertising

  2. Öö Tiib

    osmium Guest

    "Öö 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.
     
    osmium, Feb 26, 2013
    #2
    1. Advertising

  3. Öö Tiib

    Stefan Ram Guest

    "osmium" <> 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«.
     
    Stefan Ram, Feb 26, 2013
    #3
  4. On 2/26/2013 8:23 AM, Stefan Ram wrote:
    > "osmium" <> 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
     
    Victor Bazarov, Feb 26, 2013
    #4
  5. Öö Tiib

    Stefan Ram Guest

    Victor Bazarov <> writes:
    >On 2/26/2013 8:23 AM, Stefan Ram wrote:
    >>"osmium" <> 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.
     
    Stefan Ram, Feb 26, 2013
    #5
  6. Öö Tiib

    Öö Tiib Guest

    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.
     
    Öö Tiib, Feb 26, 2013
    #6
  7. Öö Tiib

    Stefan Ram Guest

    Öö Tiib <> 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).
     
    Stefan Ram, Feb 26, 2013
    #7
  8. Öö Tiib

    Öö Tiib Guest

    On Tuesday, 26 February 2013 17:20:57 UTC+2, Stefan Ram wrote:
    > �� Tiib <> 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. ;)
     
    Öö Tiib, Feb 26, 2013
    #8
  9. Öö Tiib

    Öö Tiib Guest

    On Tuesday, 26 February 2013 20:51:34 UTC+2, Paavo Helde wrote:
    > Öö Tiib <> wrote in
    > news::


    > > 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.
     
    Öö Tiib, Feb 26, 2013
    #9
  10. Öö Tiib

    James Kanze Guest

    On Tuesday, February 26, 2013 6:51:34 PM UTC, Paavo Helde wrote:
    > Öö Tiib <> wrote in


    > news::


    > > 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.
     
    James Kanze, Feb 28, 2013
    #10
  11. James Kanzeæ–¼ 2013å¹´3月1日星期五UTC+8上åˆ1時23分20秒寫é“:
    > On Tuesday, February 26, 2013 6:51:34 PM UTC, Paavo Helde wrote:
    >
    > > Öö Tiib <> wrote in

    >
    >
    >
    > > news::

    >
    >
    >
    > > > 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.


    Normally only those control parts that have to survive after an I/O or
    memory error needs to be carefully tested in the developing phase.

    Please don't all expect all programmers can design as the OS programmers
    in the application levels.
     
    88888 Dihedral, Mar 3, 2013
    #11
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Chris

    html image percentage issue

    Chris, Jul 23, 2003, in forum: ASP .Net
    Replies:
    7
    Views:
    2,293
    John Saunders
    Jul 24, 2003
  2. fake ID
    Replies:
    1
    Views:
    14,465
  3. fake ID
    Replies:
    0
    Views:
    591
    fake ID
    Feb 10, 2006
  4. Stefan Ram
    Replies:
    0
    Views:
    194
    Stefan Ram
    Feb 24, 2013
  5. Jorgen Grahn
    Replies:
    4
    Views:
    221
    James Kanze
    Feb 28, 2013
Loading...

Share This Page