Re: Percentage of error checking code

Discussion in 'C++' started by Jorgen Grahn, Feb 26, 2013.

  1. Jorgen Grahn

    Jorgen Grahn Guest

    On Sun, 2013-02-24, Paavo Helde wrote:
    > Giuliano Bertoletti <> wrote in news:5129fcf7$0$26778
    > $:
    >
    >>
    >> Hello,
    >>
    >> this might be a too generic or even an ill-posed problem, but I'll try
    >> anyway.
    >>
    >> 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.)?
    >>
    >> 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).

    >
    > Probably depends most on the programming style, not on the app type.


    Both. It can makes sense to say "we ignore memory allocation failures"
    or "it's ok to lose state on I/O errors" in some applications, but
    definitely not in others.

    > FWIW, in our codebase a typical error handling goes like:
    >
    > if (check-a-condition) {
    > throw Exception(...);
    > }
    >
    > The wc program tells me there is approximately one 'throw' for each 100
    > lines


    Ok, but throwing is less than half of the error handling. I suspect
    that with error handling done really well, most of the effort has gone
    into designing your objects so that stack unwinding Does The Right
    Thing. You may not even recognize it as "error handling code".

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
    Jorgen Grahn, Feb 26, 2013
    #1
    1. Advertising

  2. Jorgen Grahn

    Guest

    On Tuesday, February 26, 2013 10:56:02 AM UTC+1, Jorgen Grahn wrote:
    > On Sun, 2013-02-24, Paavo Helde wrote:
    >
    > > Giuliano Bertoletti <> wrote in news:5129fcf7$0$26778

    >
    > > $:

    >
    > >

    >
    > >>

    >
    > >> Hello,

    >
    > >>

    >
    > >> this might be a too generic or even an ill-posed problem, but I'll try

    >
    > >> anyway.

    >
    > >>

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

    >
    > >>

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

    >
    > >

    >
    > > Probably depends most on the programming style, not on the app type.

    >
    >
    >
    > Both. It can makes sense to say "we ignore memory allocation failures"
    >
    > or "it's ok to lose state on I/O errors" in some applications, but
    >
    > definitely not in others.
    >
    >
    >
    > > FWIW, in our codebase a typical error handling goes like:

    >
    > >

    >
    > > if (check-a-condition) {

    >
    > > throw Exception(...);

    >
    > > }

    >
    > >

    >
    > > The wc program tells me there is approximately one 'throw' for each 100

    >
    > > lines

    >
    >
    >
    > Ok, but throwing is less than half of the error handling. I suspect
    >
    > that with error handling done really well, most of the effort has gone
    >
    > into designing your objects so that stack unwinding Does The Right
    >
    > Thing. You may not even recognize it as "error handling code".


    Hey! I actively refuse to call this "error handling code". My reasoning is:what error is this "handling"?

    None: the "destruction" part of RAII (arguably, the most important part, but strangely absent in the term itself ;-)) is cleanup, and that cleanup is orthogonal to any errors that might have happened. It's pretty rare that the error and cleanup actually interact (e.g. an occasional ScopeGuard::Dismiss()).

    ;-)

    Goran.
    , Feb 26, 2013
    #2
    1. Advertising

  3. Jorgen Grahn

    Jorgen Grahn Guest

    On Tue, 2013-02-26, wrote:
    > On Tuesday, February 26, 2013 10:56:02 AM UTC+1, Jorgen Grahn wrote:
    >> On Sun, 2013-02-24, Paavo Helde wrote:
    >>
    >> > Giuliano Bertoletti <> wrote in news:5129fcf7$0$26778

    >>
    >> > $:

    >>
    >> >

    >>
    >> >>

    >>
    >> >> Hello,

    >>
    >> >>

    >>
    >> >> this might be a too generic or even an ill-posed problem, but I'll try

    >>
    >> >> anyway.

    >>
    >> >>

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

    >>
    >> >>

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

    >>
    >> >

    >>
    >> > Probably depends most on the programming style, not on the app type.

    >>
    >>
    >>
    >> Both. It can makes sense to say "we ignore memory allocation failures"
    >>
    >> or "it's ok to lose state on I/O errors" in some applications, but
    >>
    >> definitely not in others.
    >>
    >>
    >>
    >> > FWIW, in our codebase a typical error handling goes like:

    >>
    >> >

    >>
    >> > if (check-a-condition) {

    >>
    >> > throw Exception(...);

    >>
    >> > }

    >>
    >> >

    >>
    >> > The wc program tells me there is approximately one 'throw' for each 100

    >>
    >> > lines

    >>
    >>
    >>
    >> Ok, but throwing is less than half of the error handling. I suspect
    >> that with error handling done really well, most of the effort has gone
    >> into designing your objects so that stack unwinding Does The Right
    >> Thing. You may not even recognize it as "error handling code".


    > Hey! I actively refuse to call this "error handling code". My
    > reasoning is: what error is this "handling"?


    That's not very helpful IMO. To me the only sensible definition of
    proper "error handling" is whatever helps take you from an "unstable"
    error state to a stable, documented and sensible state.

    If RAII does most of the job, it would be misleading not to take it
    into account -- especially since so many programmers mess it up and
    are forced to fight errors C-style, or don't handle errors properly at
    all.

    (I'm not prepared to enter a long-winded definition battle over this,
    though.)

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
    Jorgen Grahn, Feb 26, 2013
    #3
  4. Jorgen Grahn

    Öö Tiib Guest

    On Tuesday, 26 February 2013 22:54:39 UTC+2, Jorgen Grahn wrote:
    > On Tue, 2013-02-26, wrote:
    > > On Tuesday, February 26, 2013 10:56:02 AM UTC+1, Jorgen Grahn wrote:
    > >> Ok, but throwing is less than half of the error handling. I suspect
    > >> that with error handling done really well, most of the effort has gone
    > >> into designing your objects so that stack unwinding Does The Right
    > >> Thing. You may not even recognize it as "error handling code".

    > >
    > > Hey! I actively refuse to call this "error handling code". My
    > > reasoning is: what error is this "handling"?

    >
    > That's not very helpful IMO. To me the only sensible definition of
    > proper "error handling" is whatever helps take you from an "unstable"
    > error state to a stable, documented and sensible state.


    The code in standard library (part of C++) does it without 0 effort
    from me. So C++ itself helps here.

    > If RAII does most of the job, it would be misleading not to take it
    > into account -- especially since so many programmers mess it up and
    > are forced to fight errors C-style, or don't handle errors properly at
    > all.


    That is pity, and that *is* fault of C++ tool-set (being so unfriendly
    with those poor souls who mess it up). Attitude that it is most powerful
    programming language and not kinder-garden toy feels too arrogant.

    I refuse to call whatever standard library does as "my effort of error
    handling" however. It works so well that there is hard to find
    something to improve by me despite lot of profiling, so I have chosen to
    rely on it blindly.
    Öö Tiib, Feb 26, 2013
    #4
  5. Jorgen Grahn

    James Kanze Guest

    On Tuesday, February 26, 2013 9:56:02 AM UTC, Jorgen Grahn wrote:
    > On Sun, 2013-02-24, Paavo Helde wrote:


    > > Giuliano Bertoletti <> wrote in news:5129fcf7$0$26778
    > > $:


    > >> this might be a too generic or even an ill-posed problem,
    > >> but I'll try anyway.


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


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


    > > Probably depends most on the programming style, not on the
    > > app type.


    Not really. At least not in some cases.

    > Both. It can makes sense to say "we ignore memory allocation
    > failures" or "it's ok to lose state on I/O errors" in some
    > applications, but definitely not in others.


    > > FWIW, in our codebase a typical error handling goes like:


    > > if (check-a-condition) {
    > > throw Exception(...);
    > > }


    > > The wc program tells me there is approximately one 'throw'
    > > for each 100 lines


    > Ok, but throwing is less than half of the error handling.
    > I suspect that with error handling done really well, most of
    > the effort has gone into designing your objects so that stack
    > unwinding Does The Right Thing. You may not even recognize it
    > as "error handling code".


    Most of the effort in error handling goes into deciding what is
    an error, and how to detect it. In programs with input from
    human sources, it's not rare for over half of the code, or more,
    to be error checking.

    As for designing your objects so that stack unwinding does the
    right thing, that should be more or less an automatism for C++
    programmers. Independently of exceptions, it generally results
    in cleaner and more easily understood code.

    --
    James
    James Kanze, Feb 28, 2013
    #5
    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,276
    John Saunders
    Jul 24, 2003
  2. fake ID
    Replies:
    1
    Views:
    14,323
  3. fake ID
    Replies:
    0
    Views:
    570
    fake ID
    Feb 10, 2006
  4. Stefan Ram
    Replies:
    0
    Views:
    182
    Stefan Ram
    Feb 24, 2013
  5. Öö Tiib
    Replies:
    10
    Views:
    333
    88888 Dihedral
    Mar 3, 2013
Loading...

Share This Page